Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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 [1]. 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.

[1]:
http://git.openstack.org/cgit/openstack/neutron-vpnaas/tree/tox.ini#n10

Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVcBUnAAoJEC5aWaUY1u57N2EH/jUFd0H9pQ7LApSAIlDTEl2v
WR1EXnc9Vxf5nCWq/qmncj3OCpMDlgL/ZMrFu74LRTDbe38+16kh+Fb+FvBEPGA4
ZkQC3gyg22Se/QcerTxdPil16hnT912Hr3E0cTuu/4ktyipPrVsO39N56Jbrb6WQ
SRCrEohIg7C3c0NgFcvBGh+S4rNf8IKT1oLzKrRhSLzIE8lSeGa1GNnSXPAXk19/
2KIEnqBz3Q5J6umTprB5DFdxMe93Pj6jZmGIMFaHXYgG/yTdKz3zzGM3hpuLyGUQ
kKYEzFJZ4vf2c6NBg//GYTcAkGjkM2QmAnS+uoztU5vm4QRkLgGcDCz29eQ5ufA=
=6bUu
-----END PGP SIGNATURE-----