-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix cabal install --program-suffix/prefix
(fix #10290 and #10476)
#10483
Conversation
374c1d7
to
5770ba3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Manual QA passes here also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this looks reasonable (and very much like how I remember the patch to be), we should add a regression test for this. I can try to contribute one
Thanks! It'd be awesome to get a test. I don't know when I could get to it, so please contribute! |
|
The more tests, the better! |
Yes, the more the merrier! We can spare some seconds on this provided how tricky this is. |
@fendor just to double-check: did you mean to add one more test or is it the currently posted one that takes those 60 seconds? |
@ulysses4ever The added test takes 60s on my machine, and I think it is pretty exhaustively testing the overwrite policy code path. |
Awesome! |
mm,I wonder why this is not being merged... |
@mergify refresh |
✅ Pull request refreshed |
When checking for existing installations, cabal would not account for an affix (suffix or prefix). So, if you had a `hello` binary installed, installing a second one with a non-empty affix (a perfectly legal operation) would fail. The reason seemed to be a typo in 09c04e9, which passed the arguments to the Symlink structure in a wrong order. When failing to install a binary because of an existing one, cabal would report suffix-less existing target even if a suffix was set.
Add regression tests for the `program-prefix` and `program-suffix` flags combined with the overwrite-policy. In short, the overwrite-policy needs to take potential program affixes into account when deciding whether it will need to overwrite a program path during installation.
fa72c05
to
85a4ead
Compare
Uh, there's a |
It should go in after CI completes. Meanwhile I offer you #10505 which should probably go in quickly before this happens again. |
@mergify backport 3.14 |
✅ Backports have been created
|
…10483) * fix cabal install --program-suffix/prefix (fix #10290 and #10476) When checking for existing installations, cabal would not account for an affix (suffix or prefix). So, if you had a `hello` binary installed, installing a second one with a non-empty affix (a perfectly legal operation) would fail. The reason seemed to be a typo in 09c04e9, which passed the arguments to the Symlink structure in a wrong order. When failing to install a binary because of an existing one, cabal would report suffix-less existing target even if a suffix was set. * Add regression tests for overwrite policies and porgram-affixes Add regression tests for the `program-prefix` and `program-suffix` flags combined with the overwrite-policy. In short, the overwrite-policy needs to take potential program affixes into account when deciding whether it will need to overwrite a program path during installation. --------- Co-authored-by: Fendor <fendor@posteo.de> (cherry picked from commit ee3c313)
@mergify backport 3.12 |
✅ Backports have been created
|
…10483) * fix cabal install --program-suffix/prefix (fix #10290 and #10476) When checking for existing installations, cabal would not account for an affix (suffix or prefix). So, if you had a `hello` binary installed, installing a second one with a non-empty affix (a perfectly legal operation) would fail. The reason seemed to be a typo in 09c04e9, which passed the arguments to the Symlink structure in a wrong order. When failing to install a binary because of an existing one, cabal would report suffix-less existing target even if a suffix was set. * Add regression tests for overwrite policies and porgram-affixes Add regression tests for the `program-prefix` and `program-suffix` flags combined with the overwrite-policy. In short, the overwrite-policy needs to take potential program affixes into account when deciding whether it will need to overwrite a program path during installation. --------- Co-authored-by: Fendor <fendor@posteo.de> (cherry picked from commit ee3c313)
…10483) * fix cabal install --program-suffix/prefix (fix #10290 and #10476) When checking for existing installations, cabal would not account for an affix (suffix or prefix). So, if you had a `hello` binary installed, installing a second one with a non-empty affix (a perfectly legal operation) would fail. The reason seemed to be a typo in 09c04e9, which passed the arguments to the Symlink structure in a wrong order. When failing to install a binary because of an existing one, cabal would report suffix-less existing target even if a suffix was set. * Add regression tests for overwrite policies and porgram-affixes Add regression tests for the `program-prefix` and `program-suffix` flags combined with the overwrite-policy. In short, the overwrite-policy needs to take potential program affixes into account when deciding whether it will need to overwrite a program path during installation. --------- Co-authored-by: Fendor <fendor@posteo.de> (cherry picked from commit ee3c313)
…10483) * fix cabal install --program-suffix/prefix (fix #10290 and #10476) When checking for existing installations, cabal would not account for an affix (suffix or prefix). So, if you had a `hello` binary installed, installing a second one with a non-empty affix (a perfectly legal operation) would fail. The reason seemed to be a typo in 09c04e9, which passed the arguments to the Symlink structure in a wrong order. When failing to install a binary because of an existing one, cabal would report suffix-less existing target even if a suffix was set. * Add regression tests for overwrite policies and porgram-affixes Add regression tests for the `program-prefix` and `program-suffix` flags combined with the overwrite-policy. In short, the overwrite-policy needs to take potential program affixes into account when deciding whether it will need to overwrite a program path during installation. --------- Co-authored-by: Fendor <fendor@posteo.de> (cherry picked from commit ee3c313)
…10483) * fix cabal install --program-suffix/prefix (fix #10290 and #10476) When checking for existing installations, cabal would not account for an affix (suffix or prefix). So, if you had a `hello` binary installed, installing a second one with a non-empty affix (a perfectly legal operation) would fail. The reason seemed to be a typo in 09c04e9, which passed the arguments to the Symlink structure in a wrong order. When failing to install a binary because of an existing one, cabal would report suffix-less existing target even if a suffix was set. * Add regression tests for overwrite policies and porgram-affixes Add regression tests for the `program-prefix` and `program-suffix` flags combined with the overwrite-policy. In short, the overwrite-policy needs to take potential program affixes into account when deciding whether it will need to overwrite a program path during installation. --------- Co-authored-by: Fendor <fendor@posteo.de> (cherry picked from commit ee3c313)
|
Right, that's part of what's being fixed (and for 3.12 was the source of the regression tickets, I believe). I have a backport in progress for whenever we put out 3.12.2.0. |
I'm just waiting for the next nightly to test this PR. :) |
@Kleidukos |
@Kleidukos can you try again with the current cabal-head? |
There still isn't a current one; since my fix today was based on an up-to-date repo and nobody else pushed anything while it was in CI, Mergify pushed it straight in without running the workflow. That's why part of my major CI shakeup is moving prereleases to nightly jobs; there's no way to reliably do a prerelease on merge (if we switched to GitHub's merge queues there would be a way to do it as part of the merge, but we are at this point agreed that we need Mergify AIUI). |
@geekosaur do you know why it says "7 hours ago" by the binaries on the pre-release page although it shows the commit from October 3? |
I assume at this point @Kleidukos could be better off with building master locally |
I have no idea. Certainly the commit matches the date. |
The binary inside the artifact has a date that agrees with the display above, but I note the source code links are dated October 3rd. No idea what's going on here since it shouldn't be able to access the older artifacts at this point. |
I wonder if |
@geekosaur This has been bugging me too, as a daily user of |
cabal-head from November 5th ✔️
It's good to go! |
#10290 shows: when checking for existing installations, cabal would not account for an affix (suffix or prefix). So, if you had a
hello
binary installed, installing a second one with a non-empty affix (a perfectly legal operation) would fail.The reason seemed to be a typo in 09c04e9, which passed the arguments to the Symlink structure in a wrong order.
#10476 shows: when failing to install a binary because of an existing one, cabal would report suffix-less existing target even if a suffix was set.
This turned out to be a little issue in pretty printing.
I haven't gotten around to adding tests, sadly.
QA notes
Try to check that both #10290 and #10476 don't reproduce with this patch (they both have clear instructions for reproduction).
Template Α: This PR modifies behaviour or interface
Include the following checklist in your PR: