project-cabal/pkgs/cabal.config: withBinaryFile: does not exist (No such file or directory)

[mpickering]

> cd Cabal-tests/
> cabal run Cabal-tests:parser-tests -- --accept
project-cabal/pkgs/cabal.config: withBinaryFile: does not exist (No such file or directory)

It is currently impossible to run cabal in any subdirectory of the cabal project.

This makes it hard/impossible to automatically update tests such as the parser-tests.

Can the patch responsible please be reverted quickly?

[ulysses4ever]

That's a @philderbeast's patch, I think?

[geekosaur]

I don't seem to be able to reproduce this locally with a just-built HEAD.

hilfy «cabal:master» Z$ cp $(cabal list-bin cabal) ~/.local/bin/cabal-head        
Warning: this is a debug build of cabal-install with assertions enabled.
hilfy «cabal:master» Z$ (builtin cd Cabal; cabal run -- cabal-install:cabal --help)     
Warning: this is a debug build of cabal-install with assertions enabled.
Command line interface to the Haskell Cabal infrastructure.

See http://www.haskell.org/cabal/ for more information.

Usage: cabal [GLOBAL FLAGS] [COMMAND [FLAGS]]
(...)

Your command also completes successfully. (I was going to bisect it.)

[mpickering]

I am using

cabal --version
cabal-install version 3.10.2.1
compiled using version 3.10.2.1 of the Cabal library 

You are right that HEAD appears to work.. but you shouldn't require HEAD cabal-install to develop cabal-install!

[geekosaur]

Still happens with 3.10.3.0.

[geekosaur]

You are right that HEAD appears to work.. but you shouldn't require HEAD cabal-install to develop cabal-install!

No, but

Can the patch responsible please be reverted quickly?

implies it, especially if you're talking about 3.10.2.1.

[mpickering]

@geekosaur Normal development practice is regressed because the current state of the repo doesn't work with existing developer workflows with a released version of cabal-install. (Arguably an even more critical reason to revert than a broken release)

[geekosaur]

It's already reverted. What do you want, that we retroactively re-release 3.10.2 without whatever it was?

[Mikolaj]

@mpickering: would marking 3.10.2.1 deprecated help? I'm confused. [Edit: I misread the comments]

[Mikolaj]

[Edit: this was wrong again, though less so. See another take in the next comment.]

Oh, I mis-read. You said "Still happens with 3.10.3.0". So the current stable cabal is broken in this way. So what @mpickering would need is porting the fix to the 3.10 branch (unless already ported and unless it changes the API) and releasing 3.10.4.0. Which ticket is it and which PR fixes it?

I'm afraid, unless somebody steps up, we don't have the resources to release 3.10.4.0 for a couple more months and by then 3.12.1.0 with cabal-install should be released, which contains the fix (I hope).

For now, is there an older version of cabal that doesn't have this bug? 3.10.1.0? 3.8.*?

[Mikolaj]

@alt-romes helped me understand what's probably going on:

Probably, HEAD's dev configuration (cabal files, project files, whatever) uses a new feature that cabal 3.10 does not yet support. If so, that's a case of a too short transition period between introducing a new feature and requiring it for building the project. And so, it should be reverted temporarily and brought back when cabal 3.12 or cabal 3.14 is released (maybe the latter given the damage done already).

The question is what this feature is exactly and how to revert it without breaking things (or even, potentially, with fixing bugs that the new feature fixed, in a more conservative way, for now --- but let's hope that's not the case and reverting is enough).

[Mikolaj]

Copying from the channel:

<s​clv> could be different semantics for relative paths is project import imho

[Mikolaj]

@philderbeast: you improved these or related things so you may have an inkling what's going on. Would you venture a guess?

[Mikolaj]

@philderbeast: we are discussing this in the channel right now, but I can't remember your Matrix nick. In any case, please feel free to read the channel backlog.

[geekosaur]

Okay, so I confirmed that 3.12 branch works fine. I also bisected master and tracked it down to #9565. (Which @alt-romes already guessed on Matrix.) We're now trying to figure out how best to proceed.

To summarize: we started using relative imports in cabal's source tree, which are relative to the wrong directory in 3.10.

I did not determine when the relative-directory bug was fixed on master, and don't plan to do so unless a decision is reached to release an update in the 3.10 series. (This is unlikely to happen, and if it did would be after 3.12.1.0 is released since that's our current priority after getting Cabal 3.12.0.0 out for ghc 9.10.)

[Mikolaj]

@philderbeast turns out to be on holidays, so let's handle this ourselves. If making the reverts turns our relatively painless, I'd opt for that and I take personal responsibility for the decision to revert (and I will press the big red button and then remember to merge these PRs back again in a year). Otherwise, if reverting and re-applying the conflicting PRs is particularly messy, let's try workarounds, e.g., "some kind of git clone hook to automatically substitute SOMETHING for $(pwd) in the cabal.project files". If Phil returns before we are done, I'd love to get his input, but this it git, whatever gets reverted can be rereverted, so let's not spoil Phil's holidays by blocking any design or decision on him. If there is a good workaround in 2 weeks, we can re-revert in 2 weeks.

[geekosaur]

(copied from Matrix)
I vaguely recall some early Unixy tool (possibly mh) where @ was a symlink in every directory pointing at a central resource, for convenience. Would it be possible (given, for example, the limitations of "symlinks" on Windows) to use something like this to ensure that a path relative to that within our source tree always points to the same thing?

ANSWER: apparently not. hlint recursively scans the tree and really dislikes the symlinks.
EDIT: a modified form didn't cause an infinite loop, but hlint got really slow. Dropped it.

[Mikolaj]

BTW, I was wrong saying (on the Matrix channel?) that reverting the PR could cause problems backporting things to branch 3.12 --- the PR is not on branch 3.12, so that would actually get the two branches closer.

[Mikolaj]

BTW, there's a lot of great commits in that PR, e.g., removing many unused files. Yes, it may turn out in the future we need one of these files, but I'd rather keep the commits and only revert the ones that depend on the relatives paths functionality that we can't provide in the already released cabal-install 3.10 binaries. Or maybe just copy-paste all the common project file parts instead of including them. I wonder if we'd end up with many copies of the index state stamp. That would be a major nuisance.

[philderbeast]

I'm back and will look at this today.

[Mikolaj]

@philderbeast: thank you!

BTW a detail to take care of when we re-instate the PR: the bootstrap-regenerating project file (not bootstrap-building for tests) can't have tests in it or the build plan gets too large, so this file has just been added in #9897 (edit: just merged):

cabal.project.bootstrap

Which unfortunately also duplicates index-state --- but we may have no choice in that until all reasonably new cabal binaries have correct relative path handling.

[philderbeast]

You are right that HEAD appears to work.. but you shouldn't require HEAD cabal-install to develop cabal-install!

If released cabal-install versions have a bug what is the problem with using HEAD cabal-install? Is it to avoid the build and install time cost?

$ git rev-parse HEAD
3395fa138492f4006b6be45a0b95863da60f18a2

$ cabal clean

$ rm -r ~/.cabal/store/ghc-9.8.2

$ time cabal install cabal-install:exe:cabal --overwrite-policy=always
...
Resolving dependencies...
Build profile: -w ghc-9.8.2 -O1
In order, the following will be built (use -v for more details):
 - Cabal-3.13.0.0 (lib) (requires build)
 - cabal-install-solver-3.13.0.0 (lib) (requires build)
 - cabal-install-3.13.0.0 (lib) (requires build)
 - cabal-install-3.13.0.0 (exe:cabal) (requires build)
...
________________________________________________________
Executed in  163.07 secs    fish           external
   usr time  221.26 secs  637.00 micros  221.26 secs
   sys time   12.84 secs  129.00 micros   12.84 secs

[geekosaur]

The nightly also works fine; instructions for getting it are in the README.

[Mikolaj]

If released cabal-install versions have a bug what is the problem with using HEAD cabal-install? Is it to avoid the build and install time cost?

I don't think so. It think the biggest problem is surprise and then churn. If you are new to cabal, you may spend a lot of time troubleshooting your setup before somebody remembers to ask "of course you are not using the stable cabal release?". Then let's suppose you spawn VMs for testing. First, something breaks and you need to diagnose. Then you discover it's this known problem and so from now on, in each VM instance you need to compile, copy or download a cabal version. Developer's comfort matters a lot.

[philderbeast]

surprise and then churn

I'd suspected as much. Wouldn't a lighter weight fix be prominent contributor notes about known problems and workarounds. I feel bad about adding a workaround project in #9923 and would rather it not be merged.

[Mikolaj]

Now that you say so, indeed remembering (and initially, knowing) to add --project-file=cabal.workaround.project to each invocation of run Cabal-tests:parser-tests is not substantially more light weight that copying a nightly cabal binary to, say, a VM.

Regarding well written and advertised "known problems and workarounds" section in CONTRIBUTING.md, that would be good, but even better would be an empty "known problems and workarounds" section. :)

It's really a pity one can't hardwire in parser-tests.cabal to use cabal.workaround.project by default, but then, it would be one more place where users can complicate things, making their and our diagnosis of cabal problems harder.

Are we out of plausible workarounds? If so, how about reverting? As I've written above, this is such a valuable PR that it would be best to revert it selectively, but we probably can't avoid the worst outcomes, such as duplicating index state stamps (which has already happened due to bootstrap generation in another PR). In a year or a half we can deduplicate things again, maybe including the bootstrap stamp.

Thoughts?

[philderbeast]

Are we out of plausible workarounds?

The workaround project would get picked up automatically if named Cabal-tests/cabal.project. This would serve as an invisible crutch the older cabal-install versions can use (and the HEAD one too).

Can we deprecate the older versions as far as their use in cabal development goes? They're broken for 2+ hop project imports that include relative paths, aren't they?

I'm really hoping that we can clean up our use of projects further, #9565 (comment).

[Mikolaj]

Can we deprecate the older versions as far as their use in cabal development goes?

Absolutely. Given how broken they are, half a year (as opposed to a year, I'd reflexively propose in such cases) deprecation cycle sounds reasonable.

They're broken for 2+ hop project imports that include relative paths, aren't they?

I think they are. Thank you for helping to discover that and fixing in another PR --- both unwittingly from what I gather. :D

My idea is that while we in the deprecation period for cabal development with cabal-install 3.10, we should refrain from using the features that are broken in 3.10 and that were, apparently, not widely enough used to cause problems beforehand.

I'm really hoping that we can clean up our use of projects further, #9565 (comment).

That would be amazing. And it's great we (you) are doing this gradually, letting the related errors emerge in smaller batches rather than all at once.

So, shall we temporarily revert the part of the refactor that 3.10 can't handle?

[Mikolaj]

We are in a short lull between releses 3.12.0.0 and 3.12.1.0, so let's try to resolve this one way or the other. Are there any objections to temporarily reverting the problematic part of #9565? Assuming there are none, would somebody offer to do the revert PR? I can help by reviewing and pressing the merge button myself.

[philderbeast]

Normal development practice is regressed

@mpickering could you expand on what you mean by "normal development practice" please? Are you referring to development-in-general normal, developing-on-NixOS normal (where adhoc installing may be harder) or Cabal-specific-development normal?

Do we recommend a version of cabal-install for development? If not, cabal install cabal-install:exe:cabal --overwrite-policy=always should be the recommended version, shouldn't it? That CONTRIBUTING.md leads with building Cabal for hacking suggests to me that I should install cabal-install from HEAD or use cabal run -- cabal-install:exe:cabal etc when hacking.

Note

There is no problem building the project using older cabal-install versions that choke on imports when calling cabal run from a subdirectory of the project.

[mpickering]

I expect that developers provision cabal-install from their system package manager therefore the code base should work with at least the most recent released version of cabal-install. When this error was reported I was using the most recent version of cabal-install and it couldn't perform certain tasks in the project (accepting tests in my case).

If this isn't the widespread opinion, then feel free to close the ticket but it seems quite a basic requirement of a project to me.

[Mikolaj]

Thank you for your input. However, I can see no volunteers to revert parts of the PR (and I think reverting it whole would be an overkill at this point) so maybe we could just add a note to CONTRIBUTING.md and to cabal-install 3.12 release notes recommending at least 3.12 for cabal development, with a link to this very issue? Objections? Volunteers (but if none and no objections, I'd do this myself)?