-
Notifications
You must be signed in to change notification settings - Fork 701
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
Take extra program search paths into account when searching for VCS programs. #8538
base: master
Are you sure you want to change the base?
Conversation
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.
LGTM, though it also needs a test (half-dummy is enough; even just that adding extra paths doesn't suddenly crash cabal after this change; or that mentioning the main path as the extra path doesn't cancel it out) and a changelog file.
How do I write a test for that? |
e90880b
to
84e8cbb
Compare
84e8cbb
to
acd10c9
Compare
This sounds strange. Maybe instead of using progPathExtra (as the Todo suggests) you should figure which field carries the value of --extra-prog-path and use it? It'd make more sense imho and should be easier to test too. |
Maybe not "instead" but "in addition to" rather. |
Ok, this is the
As you can see, the Since I have no understanding of Cabal internals I stopped my analysis on that. |
For almost all of us this is pure archaeology, so you are well enough equipped to reverse-engineer, document and fix, if you so choose. :) |
I lost a whole day on this "archeology" and don't plan to work on this anymore. Digging this brought me to the fact that I was just passing by and wanted to fix a simple TODO. Instead I was sent down this rabbit hole to do "archeology". The code I touched got its fix, but it is not visible due to other (bigger) problems, which I'm not going to solve. I also don't want to spend any more time on this PR, so either merge it or close it. |
@arrowd very helpful investigation, thank you! A little more inspection reveals that syncAndReadSourcePackagesRemoteRepos is only called from fetchAndReadSourcePackages, and that one is only called from two other places each of which has a handle on to a whole ProjectConfig (including projectConfigAllPackages and projectConfigLocalPackages). So, a quick and dirty solution to this problem would be to thread ProjectConfig instead of just projectConfigShared to syncAndReadSourcePackagesRemoteRepos (maybe you don’t need the whole thing but just projectConfigAllPackages or projectConfigLocalPackages would be enough: I haven’t checked). I’m a bit slow to reply these days but I wish you all the luck on earth to deal with it anyway. |
There are many other approaches one could take to solve it of course, above I only mention the easiest one. Another idea would be to look into how to set progPathExtra to something more interesting than the default. E.g. maybe --extra-prog-path could extend it too? |
Yes, I considered this, but this is a hack. The The one and only correct fix is to fix command line parsing. |
5 years ago @gbaz commited f18b082 that changed the way |
Here's why the change was made: #4995 (comment) and here's the PR that made it: If you look at the summary of the changes in that PR, I don't thank that the above description matches what happened. (it just characterizes an intermediate unsquashed patch). Rather, it just sets I'm open to suggesting that command line flag should also be taken into account. |
Yes, it did, that's the whole point of my previous comment: if you look at f18b082, it replaces
with
and this change makes Now in this context, looking at #4999: what is |
@gbaz More generally, how do I set |
The commit you are referencing is part of that larger PR. the thing it comments out was introduced incidentally in the course of that same PR. The PR as a whole does not introduce the behavior you suggest. I don't remember this PR in detail, but I think that the correct thing to do is just to change the existing --extra-prog-path flag to actually work in v2. My understanding is that before the change in that PR, neither that flag nor the cabal config way of setting it did anything much. After that PR, the cabal config way of setting it worked, but the command line way still did not. |
This is not true: just open the Not only this change made it into this PR, it's still in the code today, on master, check it out: https://github.com/haskell/cabal/blob/master/cabal-install/src/Distribution/Client/ProjectConfig/Legacy.hs#L503 (permalink). I should say, I'm slightly surprised that we keep arguing about a thing that is so easy to check. f18b082 did made it into |
Yes, the line was commented out, and the commented out line remains. But the line was introduced in 1a04a1a -- an earlier patch in the same PR. So it is not that a line that existed before was commented out and replaced. It was a line that never existed, then was introduced, then commented out, in the course of working on the same PR. Had I squashed the PR (which I now wish I had), then that commit would not exist in the history, and would not be confusing. |
Oh, gosh, now I get it. Sorry for the noise! |
This patch fixes a TODO in
syncAndReadSourcePackagesRemoteRepos
. Although I was expecting thatprogPathExtra
corresponds to--extra-prog-path
command line option, it turned out that it is always set to~/.cabal/bin
. Anyways, this makescabal-install
look into this dir first when searching for VCS executables.To test this create a following
cabal.project
:Most likely you don't have Bazaar, so
cabal build
will fail. Now runln -s /usr/bin/true ~/.cabal/bin/bzr
andcabal-install
will find it.