Hash: SHA1

On 08/14/2014 08:37 AM, Ihar Hrachyshka wrote:
> Hi all,
> some plugins depend on modules that are not mentioned in 
> requirements.txt. Among them, Cisco Nexus (ncclient), Brocade 
> (ncclient), Embrane (heleosapi)... Some other plugins put their 
> dependencies in requirements.txt though (like Arista depending on 
> jsonrpclib).
> There are pros and cons in both cases. The obvious issue with not 
> putting those requirements in the file is that packagers are left 
> uninformed about those implicit requirements existing, meaning
> plugins are shipped to users with broken dependencies. It also
> means we ship code that depends on unknown modules grabbed from
> random places in the internet instead of relying on what's
> available on pypi, which is a bit scary.
> With my packager hat on, I would like to suggest to make those 
> dependencies explicit by filling in requirements.txt. This will
> make packaging a bit easier. Of course, runtime dependencies being
> set correctly do not mean plugins are working and tested, but at
> least we give them chance to be tested and used.
> But, maybe there are valid concerns against doing so. In that case,
> I would be glad to know how packagers are expected to track those 
> implicit dependencies.
> I would like to ask community to decide what's the right way to
> handle those cases.

So I raised a similar issue about six months ago and completely failed
to follow up on the direction everyone seemed to be onboard with:

I did add support to pbr for using nested requirements files, and I
had posted a PoC for oslo.messaging to allow requirements files for
different backends, but some of our CI jobs don't know how to handle
that and I never got around to addressing the limitation.

- From the packaging perspective, I think you could do a requirements
file that basically rolls up requirements.d/*.txt minus test.txt and
get all the runtime dependencies that the project knows about,
assuming we finished the implementation for this and started using it
in projects.

I don't really anticipate having time to pursue this in the near
future, so if you wanted to pick up the ball and run with it that
would be great! :-)

- -Ben

> Cheers, /Ihar
> _______________________________________________ OpenStack-dev
> mailing list OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


OpenStack-dev mailing list

Reply via email to