I am certain there is a good reason for this, but I find the behavior of how url-specifiers in
requirements.txt are handled slightly differently from package index requirements puzzling.
I have installed a package
myproject-1.0 on my system. If I put in another project’s (
requirements.txt the line
myproject, without any version constraints then nothing new is installation during installation. However, if I put the line
myproject @ git+https://github.com/myproject.git it will pull the github repo and install the version from that repo, if, and only if it is newer (or if the hash doesn’t match?).
I would expect that similar to packages from a package index, also packages with urls won’t be reinstalled if the requirement is satisfied. I understand that this is a bit more tricky as version strings in urls might not match the package version, or a url might point to a specific package version that someone wants, but I feel there should be a mechanism to at least somehow get a similar behavior.
Where I run into this often is, when I work on a new feature that requires code being updated in both
anotherproject. In these cases I use the
--editable flag, but I always have to reinstall
myproject after I run
pip install --editable . in
Even worse, imagine the case where I have my very own specific version of
myproject installed, but then I install a package from pip that uses a url based specifier for that particular project for whatever reason, it would just overwrite my package, I might not even notice.
Is this something that could be changed?
I also wonder if there would be a point in allowing a version specifier for these packages, something along the lines of:
myproject>=1.0 @ git+https://github.com/myproject.git
If the installed version of
myproject is larger than
1.0 it won’t bother installing the url version.