Comments (17)
Closing this, I believe that this feature is a bit of an antipattern.
from pip.
+1 - we have a shared deployment library we use across ~14 applications. Each one has a deploy/
directory w/ a requirements.txt
with a single line:
deploylib>=2.14.2,<3.0.0
We try to follow semver for this library, so we only need to update this file whenever there's a breaking change and we can handle that on a per-app basis.
In general though, we'd like our devs to use the latest 2.X version of the lib - however we need them to remember to do pip install -U -r requirements.txt
for this to happen.
We could also add a wrapper script, or a Makefile, or similar, but there's no way of enforcing that they install packages that way instead of pip install -r requirements.txt
which is pretty much muscle memory at this point.
Ideally we could just add --upgrade
as the first line of the requirements file - initially thought we could do this when reading the docs, but noticed after trying that only specific pip options are supported within requirements.txt
.
We may just remove the the requirements file altogether and provide a script / makefile to install via pip
cli directly.
from pip.
Hmm. The other workaround, of course, is to just instruct people to use "pip
install -U -r requirements.txt". Obviously this doesn't allow you to decide
per-requirement.
Original Comment By: Carl Meyer
from pip.
Right, and I'd really prefer it to be per-requirement, and bake it into the
req file rather than making the user remember a flag.
Another option would be for pip to get smart about scripts, and make local
copies with munged shebang lines, but that sounds horrible and insane if it's
even possible to find the scripts to copy.
Original Comment By: slinkp
from pip.
Also filed as a virtualenv bug, but it looks like there is nothing virtualenv can do about it:
pypa/virtualenv#124
from pip.
Also noting that the right command-line workaround is probably -I, not -U.
I'd actually love to be able to put either of those in a requirements file, but -I is probably more important (if you just want "the latest" why are you putting that in a req file?)
from pip.
Well, the "right" workaround for now is a little tricky. -I is ugly as a general recommendation because it really does pretend nothing else is installed, so it won't uninstall a previous version before installing a new one, which can lead to odd bugs if you are actually upgrading. If you know you've got a clean virtualenv and just want it to ignore global stuff, then -I is good. And -U also works fine, but only because it's buggy and reinstalls even if the same version is already installed :-) It still respects version-pinning, so there's no harm in using it with a fully version-pinned requirements file.
In any case, the right fix here is a new option that we don't have yet: --ignore-global or some such spelling, which ignores anything that isn't in the site-packages you're about to install to, but still does proper uninstall-on-upgrade.
I'm not convinced this new argument needs to be usable per-line in a requirements file (that'll make it somewhat harder to implement, I think). I'm open to convincing use cases, but I think if we had this argument it could safely just be applied to the entire requirements file if you know that scripts might be involved - disk space is cheap :-) It should definitely be something you can put on its own line in a requirements file and have it apply to the whole file, like e.g. --index-url.
Pull requests welcome!
from pip.
Ah, thanks for the insight on -I.
-U is not buggy, that's just an undocumented feature :)
Disk space is cheap, but packages with C dependencies can be a big source of installation pain depending on how hard they are to build. In fact those are the only reason I don't normally tell people to use virtualenv --no-site-packages
, and for the same reason I'd much rather have the per-line-in-requirements-file version of this proposed feature.
I like telling users to do apt-get install lxml python-gdal python-imaging numpy
or their platform's equivalent. I don't want to go back to telling them to install gcc, libxslt, and a dozen other things that neither of us really cares about and whose names are sometimes hard to discover - and may even change between OS distribution releases (grrr thanks a lot for that, Ubuntu).
But then, if I ever needed a console script provided by a package with C extensions, I'd still be screwed :-\
from pip.
The -U bug definitely feels like a bug when you want to upgrade a big list of packages to latest versions, and most of them are already at the latest version, and some of them are big... of course, I almost never want to do that, but some people do. Or so I'm told.
So if you have people install big C stuff with OS packages, why do you need those things in the requirements file at all? I guess just for consistency, being sure it's there one way or another...
In any case, my hesitation about per-line is pretty much just implementation complexity. So if a pull request shows up on my doorstep with an implementation that lets it be set per-line, and isn't terribly ugly, I won't turn it down...
from pip.
The information about package update strategy can be obviously baked into requirements file this way now:
# requirements.txt
-r base.txt
-r apps.txt
'base.txt' contain all those long-to-install packages that should usually be only installed once:
# base.txt
PIL
lxml
and the 'apps.txt' contains requirements that are updated more or less regular:
# apps.txt
some-small-package-1
some-small-package-2
And then: pip install -r base.txt (or pip install -r requirements.txt), pip install -U -r apps.txt
So is the original ticket about providing some syntax sugar for the example above?
from pip.
So is the original ticket about providing some syntax sugar for the example above?
No, it's about providing a way to ensure that a package will actually be installed inside a virtualenv, even when the same package is already installed in global site-packages (and the virtualenv doesn't use --no-site-packages). Particularly for packages with scripts, where the globally-installed script won't run within the virtualenv.
from pip.
Hm, based on carljm's response, I think -U is not the right feature to leverage for this: I don't really want to force download/install every time pip is run, I just care about forcing a local installation once so that scripts work.
Maybe this would have to be a new command-line option too: --force-local/-F or something.
But that raises more questions about how it would be implemented and what it should do if you're not in a virtualenv (bail out with an error? do nothing?).
kmlke's suggestion might be an adequate workaround for me right now although it could get hairy if the order of installation matters (eg. what if a package in base.txt depends on a package we want to install with -U? For pip to get the right version installed, the latter needs to be installed during the same run, so we can't put it in apps.txt. Listing it in both files might work but, yuck.)
from pip.
#353 offers a reminder that the new flag here, --ignore-global or --force-local whatever we call it (it could even just be --local, since we already use that for freeze in a parallel way) needs to also respect --user and consider the user installation dir a distinct "local environment" much like a virtualenv.
from pip.
Also just noting, since I hadn't realized this, that "-I" applies to everything -- including dependencies, not just the requested package(s). It really does mean pretend nothing is installed.
from pip.
As there is a way to specify an option for VCS, is should be possible to have
-I packagename>=package-version ?
from pip.
Any progress on this?
from pip.
Take a look to contraints
https://pip.pypa.io/en/latest/user_guide.html#constraints-files
from pip.
Related Issues (20)
- Hash comparison is case-sensitive
- [Documentation] Improve the documentation for pip.ini / pip.config
- Add / Extend Pip install command to automatically update the requirements.txt file HOT 1
- pip problem being recognized. HOT 1
- Installation error for package with un-normalized extra names in pip 24.1b1 HOT 10
- Possible to configure "truststore" to be persistent? HOT 5
- pip does not work with development versions of CPython due to parse error on version string HOT 6
- ModuleNotFoundError: No module named 'pip' HOT 2
- Command - pip reset HOT 6
- python -m ensurepip doesn't create the pip.exe shortcut on python-3.13.0b1 HOT 2
- installing via "git+file" fails under Windows when url point to different drive-letter HOT 1
- Pip >22.2.2 fails to install package from a proxy mirror of PyPI, but can do so directly from PyPI HOT 9
- "No module named 'Cython'", but only when installing a package and only with pip 23.1 or later HOT 2
- ERROR: Fatal Internal error [id=1] HOT 4
- Improve the release process to enable trusted publishing HOT 1
- Improve UX and Performance of Install step HOT 6
- Show the detailed error when facing invalid requirements HOT 6
- pip-24.1b1 doesn't tolerate anymore a contraint like 'python-hdf4>=0.10.0+dummy' HOT 5
- pip --no-input will still prompt for git and ssh
- Ongoing CI issues on `main` HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pip.