Drop file and module targets

[andreabedini]

It looks like the ability of compile sub-component targets (i.e. single files and single modules) has been sitting half backed for many years. This PR indends to remove what is effectively dead code.

cabal-install has a lot of logic to support many different forms of target selectors (see TargetSelector.hs), only to drop the whole thing on the floor when it comes to call Cabal.

https://github.com/haskell/cabal/pull/8966/files#diff-2adae381a2eb2d8c804d5396694a431e1e3babd816a5d2408a62213cf774a893L3132-L3134

Similarly Cabal implements complex matching logic to parse sub-component targets (so it seems to be aware of the functionality it does not yet have) only to give up at the end

https://github.com/haskell/cabal/pull/8966/files#diff-92dccb98376c4c010aaedf4bbea0733e6ab8016318f0038db9ccf4e366fd9e95L1059-L1067

I suggest all this can go, shaving ~1200 loc. I am also confident all this can be done in a simpler way, if and when we decide to have this functionality.

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• Include manual QA notes if your PR relates to cabal-install.

Bonus points for added automated tests!

[andreabedini]

I am afraid this got hit badly by the reformatting :-/ I'll pick it back up another time.

[Kleidukos]

@andreabedini would you allow me to fix this?

[andreabedini]

@andreabedini would you allow me to fix this?

Absolutely 😂 I don't feel obliged though :-) Do you have any trick up your sleeve to deal with the situation?

[Kleidukos]

Yes I plan on recreating your changes based on the latest HEAD instead of resolving conflicts by hand. :)

[sheaf]

Any updates on this front?

[andreabedini]

Any updates on this front?

This got bitrotten by the codebase formatting. I guess I could give this another go.

[andreabedini]

Redoing this wasn't hard in the end, but I must have broken something for the cabal script.

[andreabedini]

Alright I understood what is going on.

In affected test, we have a package with executable foo and main-is: Main.hs. We then check that cabal run Main.hs fails because we say it is meant to run individual haskell files and not files which are part of a package component. The message that the test expects is:

# cabal v2-run
Resolving dependencies...
Error: [Cabal-7070]
The run command can only run an executable as a whole, not files or modules within them, but the target 'Main.hs' refers to the file Main.hs in the executable foo.

After removing sub-component targets, there is no target for "a file part of a component", so that check disappears and we get a more down to earth message:

# cabal v2-run
Error: [Cabal-7121]
Failed extracting script block: `{- cabal:` start marker not found

which is also expected and correct since Main.hs does not have the start marker.

I am inclined to think we can accept this new behaviour: cabal run <file> does less guessing and checking and simply looks at the start marker; if there is a marker cabal uses it, otherwise it complains.

[andreabedini]

@Kleidukos @Mikolaj @ulysses4ever @sheaf what do you think?

[Mikolaj]

I'm really too ignorant here to comment but, yes, let's drop and delete it all!

[andreabedini]

I maked this as ready and updated the description.

[ulysses4ever]

Sorry, busy end of year, haven't gotten any cycles to look into this. On the surface of it sounds fine.

[sheaf]

I agree with your assessment that it's better to remove this effectively dead code rather than hope it will eventually be resuscitated into a working feature.

[mergify]

refresh

✅ Pull request refreshed

[ulysses4ever]

Perhaps, it needs a manual rebase on master.

[Mikolaj]

Isn't it all fine now? Mergify just waiting the 2 days after 2nd review?

[ulysses4ever]

The reason I mention manual rebase is that GitHub UI says there are conflicts that cannot be automatically resolved. I don't know what Mergify will do about it. We can wait and see.

[Mikolaj]

@ulysses4ever: I see "This branch has no conflicts with the base branch". Am I looking in the wrong place or do you need to reload the page?

[ulysses4ever]

@Mikolaj

[Kleidukos]

@ulysses4ever welcome to the Twilight Zone I guess

[Mikolaj]

"Impossible" happened, I suppose? Run for the woods?

[geekosaur]

Actually, if you select the dropdown next to "Update branch", you will find that "Rebase" is grayed out with a message "This branch cannot be rebased due to conflicts". Apparently merge is okay, though.

[Kleidukos]

oh yeah if you make a merge commit then it will "work"(??)

[geekosaur]

IIRC both would run into conflicts but only github's merge code knows how to deal with them at present? From a local checkout you can fix conflicts and git rebase --continue.

[andreabedini]

Here it says no conflicts 🤷‍♂️

[geekosaur]

[Mikolaj]

Actually, if you select the dropdown next to "Update branch", you will find that "Rebase" is grayed out with a message "This branch cannot be rebased due to conflicts". Apparently merge is okay, though.

Oh, so that's it! I think rebase is more strict than merge, so no wonder. If the commits are going to be squashed, no harm in merging (I forgot, does mergify merge or rebase when it's going to squash?), except that rarely some subtle merge errors may occur (e.g., wrong line order) when rebase would just refuse to cooperate.

[ulysses4ever]

Just when you thought you understood git, git strikes you in the back ...

The only explanation I can think of has to do with multiple commits. Rebase tries to apply every commit in order and can fail on some of them. Whereas merge tries to reconcile the final states of two branches.

II wonder if this is the case that with a single-commit PR rebase and merge will always have the same outcome in terms of conflicts…

And then the whole other trap is GitHub's dreadful UI feature that remembers your last PR action (rebase vs merge vs squash). Thanks to it, everyone can see something different... (Well, no more than three options.)

[andreabedini]

For security reasons, Mergify can't update this pull request. Try updating locally. GitHub response: refusing to allow a GitHub App to create or update workflow .github/workflows/validate.yml without workflows permission

Maybe this is something we can fix?

[Mikolaj]

For security reasons, Mergify can't update this pull request. Try updating locally. GitHub response: refusing to allow a GitHub App to create or update workflow .github/workflows/validate.yml without workflows permission

Maybe this is something we can fix?

Did it fix itself?

[andreabedini]

Did it fix itself?

I rebased manually ☺️