Open Stack

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

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud