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 (anotherproject
) 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 myproject
and anotherproject
. In these cases I use the --editable
flag, but I always have to reinstall myproject
after I run pip install --editable .
in anotherproject
.
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.