-----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----- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
