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 <[email protected]> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
