-
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
"pip wheel" does nothing if a wheel is available from PyPI #1310
Comments
I agree it should find the setuptools wheel and place it into your wheelhouse. marking this as a bug. |
I'm having the same issue with django-appconf. |
Actually, my problem is that I'm trying to update my |
This is a bit of a brutal hack, but this is my workaround:
|
@jbalonso Thanks, works like a charm! |
I have a similar situation, although in our case the issue is not directly related to PyPI, but using --no-index --find-links="wheelhouse". We have been using pip bundle for application packaging, but my goal now is to set up a central wheelhouse (similar to PyPI) to store wheels after building them. |
+1 for me as well. |
If the behaviour were to change so that pip instead did not ignore packages already found as wheels (i.e. cache all packages requested, as wheels full stop), which I think is a more sensible and intuitive default, I'm wondering if there's a use case to warrant adding a flag to revert to the current behaviour? |
This is also currently different behavior than the documentation suggests. |
let me add a warning in the docs for now, until this get's fixed. |
If I'm not mistaken, this issue tracks the bug discussed in the article "Python on Wheels?" (See here) |
I'm working on this, so should have a PR soon. |
closing due to merge of #1524 |
Tested, works for my use-case (local wheelhouse). Downloading PyPI wheels works too. Thanks! |
Any chance to make 1.5.3 with this fix? Right now stable pip version is just broken, and 1.6 may be months away (guessing from release history). |
@qwcode I'm happy enough to see a new release (but I'm not the one doing the work :-)) It would be good to get this fix into the version shipped with Python 3.4. |
Seems reasonable to me to roll this into the 1.5.X branch. |
ok, I'll push it over later. |
I have the push ready, but too many problems atm, due to bitbucket being down |
ok, pushed to 1.5.X (along with #1527) with a successful travis build. |
Mmmh, this bug actually was a feature for me: I was happy that in the wheel dir only those packages ended up which are not already found somewhere (--find-links). This is really helpfull if you need to build/maintain a local (no access to pypi.python.org) wheelhouse, in my case a local devpi. Maybe it would be possible to introduce a --no-copy flag if someone only wants to have those wheels which are not already existing and just copied? Best would be if one could specify from where the wheels are copied (outside firewall e.g. pypi.python.org) and from where not (inside firewall, local wheelhouse) |
a |
+1 for |
I'd like to be able to "pip wheel --wheel-dir=/path -r requirements.txt regardless of whether there's a PypI wheel so that I always have a backup I can use. I'd think this would be desirable since it would reduce PyPI traffic. |
Use case: I'm preparing a
wheelhouse
with dependencies for our product as wheels. The installation afterwards is supposed to run only from these wheels, i.e. also with--no-index
.However,
pip wheel
fails to actually download a wheel if it's available from PyPI. For example, I would like to have a wheel forsetuptools
locally:I would expect
pip wheel
to create correct wheels in every possible way: by compiling, downloading or otherwise. It should only skip doing anything if there is a correct wheel file in the target directory.The text was updated successfully, but these errors were encountered: