[openstack-dev] [all][infra][requirements] Odd cases in requirements?

Akihiro Motoki amotoki at gmail.com
Mon Sep 5 10:14:52 UTC 2016


2016-09-05 16:03 GMT+09:00 Andreas Jaeger <aj at suse.com>:
> On 09/05/2016 07:45 AM, Tony Breeds wrote:
>> On Sat, Sep 03, 2016 at 07:33:42PM +0200, Andreas Jaeger wrote:
>>> Reviewing all the constraints work, I see that repositories have created
>>> some workaround around requirements install for one of these two legimit
>>> reasons - most often using tools/tox_install.sh from tox.ini for it:
>>>
>>> 1) The repository is a dependency of another one and uses constraints,
>>> so edit upper-constraints file and allow git install.
>>>
>>> Example:
>>> http://git.openstack.org/cgit/openstack/ironic-lib/tree/tools/tox_install.sh
>>>
>>> 2) Install a package that is not on pypi. This is typical neutron or
>>> horizon.
>>>
>>> Example:
>>> http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/tools/tox_install.sh
>>>
>>> Note there's a third usage as well: Install packages that are not in
>>> global-requirements but let's leave that use case out of this discussion.
>>>
>>> For 2, Robert Collins has started in
>>> https://review.openstack.org/#/c/252680 a way to check out the required
>>> repos - but that change is incomplete and looks orphaned.
>>>
>>> Instead of several projects copying and adopting these files - and thus
>>> having them in various state in repositories - what can we do to make it
>>> easier for developer and projects to address these two problems?
>>
>> Hi Andreas,
>>     Thanks for bringing this up, it's been on my radar for a while but I haven't
>> made much forward progress apart from a few quick conversations.
>>
>> Fixing the first item you point out need to be done in pip, and as always there
>> is a balance between doing it fast and doing it right.  The requirements team
>> has this item on it's todo list for Ocata.  In the meantime we could look at
>> simplifying the scripts in use if that's of any benefit.
>
> Glad to hear!
>
>> The second item has always confused me slightly.  I'm not sure why projects
>> that need horizon/neutron have a tox_install script, can't they just add
>> something like:
>>
>> "-e git://git.openstack.org/openstack/neutron@master#egg=neutron"
>> or
>> "http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon"
>>
>> in test-requirements.txt ?  Actually I see from [1] that quite a few horizon
>> plugins are doing just that.  I wonder if that'd work better for neutron?
>>
>> Yours Tony.
>>
>> [1] http://codesearch.openstack.org/?q=horizon-master.tar.gz&i=nope&files=test-requirements.txt&repos=
>
> Indeed, these work in general - but not with Depends-On, so if you want
> to test a proposed change in horizon together with a change in say
> mistral-ui.
>
> Not sure how much that is a problem for horizon or neutron,

IIRC, neutron introduced tox_install.sh first and
I think it was to support Depends-On mechanism.
The main histories are found in openstack/neutron-lbaas repo:
c61f920f2a54fd829ee37484b3743ab77b909847 (tox_install.sh was introduced)
eb41ab78b87f1589fada5fca0c9189fa361d6289 (stop specifying neutron in
requirements.txt)

For Horizon, I am the person who started to tox_install.sh.
Horizon plugins did not use Depends-On to Horiozn patch frequently.
The main reason was to fix https://bugs.launchpad.net/devstack/+bug/1540328 .
It is similar situation to neutron.

Hope this helps you.

Thanks,
Akihiro


>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>    GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>        HRB 21284 (AG Nürnberg)
>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list