Open Stack

On 06/03/2015 11:08 PM, Robert Collins wrote:
> Hi, right now there is a little used (e.g. its not in any active
> project these days) previous feature of pbr/global-requirements: we
> supported things that setuptools does not: to whit, tarball and git
> requirements.
> 
> Now, these things are supported by pip, so the implementation involved
> recursing into pip from our setup.py (setup.py -> pbr -> pip). What we
> exported into setuptools was only the metadata about the dependency
> name. This meant that we were re-entering pip, potentially many times
> - it was, to be blunt, awful.
> 
> Fortunately we removed the recursive re-entry into pip in pbr 1.0.
> This didn't remove the ability to parse requirements.txt files that
> contain urls, but it does mean they are converted to the simple
> dependency name when doing 'pip install .' in a project tree (or pip
> install $projectname), and so they are effectively unversioned - no
> lower and no upper bound. This works poorly in the gate: please don't
> use tarball or git urls in requirements.txt (or setup.cfg for that
> matter).
> 
> We can still choose to use something from git or a tarball in test
> jobs, *if* thats the right thing (which it rarely is: I'm just being
> clear that the technical capability still exists)... but it needs to
> be done outside of requirements.txt going forward. Its also something
> that we can support with the new constraints system if desired [which
> will operate globally once in place (it is an extension of
> global-requirements)].
> 
> One question that this raises, and this is why I wrote the email: is
> there any need to support this at all:- can we say that we won't use
> tarball/vcs support at all and block it as a policy step in global
> requirements? AIUI both git and tarball support is problematic for CI
> jobs due to the increased flakiness of depending on network
> resources... so its actively harmful anyway.
> 
> -Rob

With my package maintainer's hat on, I really would like this feature to
go away as well.

"the latest commit from this git repo" doesn't express anything
packageable, and it always feel confusing when reading it. Also, some of
my toolings (very internal automation stuff with openstack-pkg-tools for
semi-automatically maintaining Debian dependencies) don't support it also.

Thomas