Don't add extra-prog-path to ~/.config/cabal/config (#8951)

[sol]

(when initially creating it)

This partially addresses #8951.

---

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!

[Mikolaj]

@sol: may we help you with the CI? I guess the last failure is expected (tests needs to be adjusted)? Is there anything else in the CI log that is concerning?

[sol]

@Mikolaj I rebased and adjusted that test.

[Mikolaj]

LGTM given my limited understading.

[ulysses4ever]

There's another PR in flight that claims to resolve the same ticket? #8972

[sol]

There's another PR in flight that claims to resolve the same ticket? #8972

@ulysses4ever "We could (and probably should) do both."

#8951 (comment)

[Kleidukos]

Non-blocking: I'd love a short description that would explain the benefit (which we all know, but that would save some pointer chasing for the casual reader in the changelog interface of the package index.)

[Mikolaj]

@sol: how about this extra explanation?

[Mikolaj]

It seems this one is not going to make it in time for 3.10.2.0 and we don't want to rush anything in a point release, unless a regression is super-terrible.

[sol]

we don't want to rush anything in a point release, unless a regression is super-terrible.

I don't want to be overly dramatic, but this regression (== the regression introduced with #8506) can silently corrupt builds.

Why is that? Because a failing build due to the wrong version of a build tool being used is actually the best case scenario here. What might happen instead is that the build succeeds, possibly producing a different result.

It's not just hypothetical. I spent a whole day debugging this, and I didn't do so for no reason. I did it, because there was something fishy, because cabal did not do what I specified in the .cabal file.

from what I understand, when a feature introduces a regression, there are two ways to address this: Either revert the feature, or fix the regression.

So I would hope that either

• prepend rather than append extra prog path #8506 is reverted
• or at least one of Don't add extra-prog-path to ~/.config/cabal/config (#8951) #8952 or Fix precedence for PATH for build-tools-depends #8972 get into the next bug fix release

For this PR, is the issue that we don't have the second approving review? If yes, @gbaz can you take a look?

[gbaz]

I think 8972 is the most important thing to merge. This PR only affects first-time cabal users, as otherwise configs tend to have settings inherited from prior cabals instead of being generated afresh. Its probably a worthwhile cleanup regardless, that said, in that when installing with e.g. ghcup, the cabal bin path gets added to the path anyway.

[sol]

when installing with e.g. ghcup, the cabal bin path gets added to the path anyway

To put it more concretely for the casual reader:

• You want the cabal bin dir on your PATH. That's completely fine and does not interact in anyway with this story / regression.
• On the other hand, having the cabal bin dir as extra-prog-path is at best useless and as of now proliferates this regression .

[Mikolaj]

In that case let's merge (perhaps speeding it up by setting merge_delay_passed manually) and then try to backport.

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[Kleidukos]

@Mergifyio backport 3.10

[mergify]

backport 3.10

✅ Backports have been created

• #9050 Don't add extra-prog-path to ~/.config/cabal/config (#8951) (backport #8952) has been created for branch 3.10 but encountered conflicts