[openstack-dev] [global-requirements][pbr] tarball and git requirements no longer supported in requirements.txt
ihrachys at redhat.com
Thu Jun 4 09:06:51 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
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.
Lots of Neutron modules, like advanced services, or out-of-tree
plugins, rely on neutron code being checked out from git . I don't
say it's the way to go forward, and there were plans to stop relying
on latest git to avoid frequent breakages, but it's not yet implemented.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the OpenStack-dev