-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Make suggestion when the current stable version has no wheel but a pre-release does #4795
Comments
This is normal,
|
Adding to what @benoit-pierre said, you'd probably want to do:
|
I understand that this is a small use case (a few months ago SciPy couldn't even be compiled on windows), but IMHO it's worth considering an improved user experience here. I suggest a simple warning message when there is a pre-release wheel available but only a source distribution for the stable version:
|
My answer would be: "please try again" :) Now SciPy has wheels for Windows. |
Has this been marked as a feature request yet? Edit: I think that it might be best to put that as its own issue for searchability and clarity |
? |
Maybe I'm just being dumb (please tell me if I am) |
I am very indecisive about things like this. Always have, most likely always will be. I think it's some kind of social anxiety as I feel like I will be wasting other people's time no matter what I choose to do sometimes. |
I marked this issue as a feature request, as you asked. You closed it (about the same time). I'm confused too. As a closed feature request, no-one is likely to do anything about it. If you'd left it open, then it's waiting for someone to submit a PR (maybe you, maybe someone else). I certainly don't mind it being marked as a feature request. That doesn't waste anyone's time - it just flags it as a possible enhancement that would be useful to someone, and might be something that someone would like to pick up and implement. You've highlighted an area where pip could be improved, that's a useful contribution even if nothing further ever happens, and it's appreciated. |
alright |
I created a minimal package I first tried to install it without providing the
Now when I provided the
So now, if I understand correctly, for this feature, we should be printing the warning |
Also related is #7579, which proposes to change the behaviour and just let pip find rc versions when no stable matches are available. |
Thanks for the reference. That change seems to require a PEP update as per #7579 (comment) , which IMO is a much larger change, w.r.t this issue which is to try and find a pre-release version match according to the specifier, and suggesting the user that such a version is available and can be installed. Considering these facts, should I go ahead and attempt this change in a PR, or we should way for resolution of #7579 , at which point this will automatically be resolved? |
I don’t think anyone is actively pushing a PEP change on this. Better go on and attempt the error message if you want to get this resolved. |
Sure will do. But I am still wondering if this is a beneficial change, and the warning/suggestion about trying to install a pre-release actually help the user? |
IMO the message would be quite useful, at least from my own experience. |
Okay, I will create a PR for the same then. Also, IIUC, pip/src/pip/_internal/index/package_finder.py Lines 461 to 473 in 6a7bf94
is where we decide whether to include or exclude prereleases. So either we can
I would be happy to hear your thoughts on both of these, or if there are better ways of doing this then these two. |
@deveshks I like the first approach better |
On thinking further, I actually think that the situation where a pre-release has a wheel, but a stable version does might be infrequent (For e.g. in pip, we only had pre-releases for about 2 weeks, before we will have a full release). So the second approach of considering pre-releases in the search lazily might be better, rather than eagerly searching for all pre-releases always, but since most of the times there would be a stable release found. But I will wait for others to chime in before deciding on the approach |
I'm now confused as to what's being proposed here. To state my views:
So adding a warning is probably OK in theory, but I don't think there's any particular evidence that it would be useful in practice. |
Agreed. The final outcome of a PR generated from this will be to just to suggest the user about potential installation options, and not to change the default behaviour in any way.
I think I misread the intentions of the OP and assumed that we needed to provide a warning when pip fails to install anything but there's pre-releases available, and your outline above is the actual problem faced. But I agree that the user can figure this out on it's own as well, and the warning won't serve a real purpose. Thanks for the clarification.
Agreed, and I think we won't go that route.
I think this is a better problem to handle, but it might be out of scope of this issue, and would warrant a new issue IMO
Yes, from the different points you raised, I guess the warning might be too intrusive, or not very helpful. So if we want to address point 4, a new issue can be created. Otherwise we can go ahead and close this issue. Also please feel free to correct me in the understanding of any of the points I mentioned above 😊 |
Description:
I was trying to install two Python modules, NumPy and SciPy, NumPy installed successfully but SciPy did not. After a while of trying to figure out why it was complaining about missing a bunch of files I decided to check on PyPi to see if there was an alternate download. And, lo and behold, none of the files listed for download were for version 0.19.1, which pip said was the most recent, but instead version 1.0.0rc2, released today (October 18th). After a bit of trial and error, I worked out how to force-feed the file to pip.
What I've run:
I copied the entire cmd prompt session into the attached txt file below
pip-bug_cmd-line-output.txt
Expand for log (edited by @pradyunsg)
The text was updated successfully, but these errors were encountered: