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