Url requirement specifier not entirely consistent with pip specifier

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.

If you actually mean “install a package from PyPI” here, PyPI doesn’t allow uploading packages with URL specifiers, so this isn’t a concern.

@jwodder Thanks. I didn’t know that, good to know. That mutes my second concern somewhat.