Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
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:
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026976.html

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

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

iQEcBAEBAgAGBQJT7OS8AAoJEDehGd0Fy7uqtqsH/0kcIB+Q9iA5vR5evC+PDsFb
ek+cwvldbgpv0JwFwhgsLtsbRbI9xv1wDpu8L5i30yKzgcPQX5cqYe2WZeG5eCBJ
HUHb3t86rCanBU+kp7hpjHSoQbdwhY9gtu1LwiVha/2IeOHchZBzJccxEcACsv0q
Es8YkQy3qp9EfegumaL4OHvYFfB/j4NbewxZjAb3mkcpObb6NBM1v+qeubjTEg5I
nY8lJMLBXJOLNrR5cg8G7sObh3Cow51GtjwFaiFuZi/9o6whQFXipKnwXkaSRR5U
I3YV18sy3NLtoStZdr4/Oa9kUICw1MdDZAckoc5nP+AQeZCBFaPaCPpkLzIcMT8=
=CdPl
-----END PGP SIGNATURE-----