Make sure that OPAMROOT and OPAMSWITCH are properly set when executing build commands - #4668
Conversation
|
Ouch! Thanks for spotting and fixing this. I think we should fix it more defensively, though:
However, this is a breaking change, albeit a sensible one. It is possible to workaround the present behaviour by explicitly passing |
|
Is this what you propose? |
|
Yes, except for |
2f76f92 to
b83f7e1
Compare
|
Done |
b83f7e1 to
8482b06
Compare
|
Thanks for the fast updates! This looks fine to me (assuming CI agrees), we just need to determine whether the "breakage" is OK |
|
I'll take a look to failing tests. |
|
héhé in fact the PR fixed the test. It was kept on purpose ^^ (to be checked later) |
|
Updated with a test for this specific case. Otherwise, lgtm! Thanks @LasseBlaauwbroek ! |
|
Thanks, @rjbou! We just now need to decide whether this is 2.0+, 2.1+ or 2.2+ 🙂 |
|
Thanks @rjbou! Regarding versions: It seems to me that If this is breaking, and it is happening in a 2.x, then it might as well be the most recent unreleased one, so 2.1. I would say it is exceedingly unlikely that a package or workflow is relying on an incorrectly set root or switch specifically for |
|
@LasseBlaauwbroek - it is definitely a breaking change! We already have |
|
Sure, I agree it is breaking. I'm just suggesting that the break might as well be early then (in 2.1) because the breakage seems exceedingly small and it'll have to break at some point. |
dra27
left a comment
There was a problem hiding this comment.
Discussed this morning, and approved for 2.0.9 and 2.1, thanks!
If one installs a package in a root or switch that is not currently active, and that package calls the
opambinary during installation, it will not see the correct root/switch because the environment variables are not set.Examples: