4

When configuring install_requires=[...] in a setup.py file, we can specify either version numbers:

package >= 1.2.3

or a source:

package @ git+https://git.example.com/some/path/to/package@master#egg=package

But I did not manager to specify both, I got an error for everything I tried.

Looking at the PEP 508, it looks like it is intended:

specification = wsp* ( url_req | name_req ) wsp*

where wsp* just means optional whitespace.

  1. Did I get it correctly that it is not possible to write something like this? package >= 1.2.3 @ git+https://...

  2. What is the reason for this decision?

JD D
  • 7,398
  • 2
  • 34
  • 53
VPfB
  • 14,927
  • 6
  • 41
  • 75
  • 1
    Because a URL is by definition "a specific artifact to install". You get whatever that points to, so adding further constraints makes no sense. – Masklinn Mar 25 '20 at 12:01
  • I think it makes sense as a safety measure. – VPfB Mar 25 '20 at 14:34

1 Answers1

2

I believe this is because getting a python package from a URL/Github does not have a way to get historical builds/packages like you would via packages stored via PyPi.

Github/URLs references a single snapshot of code, you could sort of simulate getting specific versions if you have tags or release branches in GitHub and update the URL to reference those versions:

git+https://git.example.com/some/path/to/package@master#egg=package git+https://git.example.com/some/path/to/package@develop#egg=package git+https://git.example.com/some/path/to/package@1.4.2#egg=package

JD D
  • 7,398
  • 2
  • 34
  • 53
  • 1
    the PEP actually mentions that URLs are "a specific artifact to install", whether it's VCS or HTTP you get what's at that URL and that's it. – Masklinn Mar 25 '20 at 12:03
  • It is difficult to verify an answer based on a speculation. I appreciate it anyway. – VPfB Mar 26 '20 at 20:14
  • I agree but I didn't have a chance to do the proper look ups but it appears that Masklinn confirmed so i'll take the speculation comment out of the answer – JD D Mar 27 '20 at 18:57