Open Stack

+1. I had setup a CI for a third-party plugin and the easiest thing to do
to make sure it was running tests with the latest copy of the corresponding
neutron branch was to put the git URL in requirements.txt.

We wanted to always test the latest code so we had early detection of
failures. What's the appropriate way to do that without using a git
reference?

On Thu, Jun 4, 2015 at 2:06 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> -----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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/11d4a678/attachment.html>