-----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 OpenStackemail@example.com > 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----- _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev