Excerpts from Monty Taylor's message of 2018-04-12 13:54:46 -0500: > On 04/12/2018 11:27 AM, Clark Boylan wrote: > > On Wed, Apr 11, 2018, at 5:45 PM, Matt Riedemann wrote: > >> I also seem to remember that [extras] was less than user-friendly for > >> some reason, but maybe that was just because of how our CI jobs are > >> setup? Or I'm just making that up. I know it's pretty simple to install > >> the stuff from extras for tox runs, it's just an extra set of > >> dependencies to list in the tox.ini. > > > > One concern I have as a user is that extras are not very discoverable > > without reading the source setup.cfg file. This can be addressed by > > improving installation docs to explain what the extras options are and why > > you might want to use them. > > Yeah - they're kind of an advanced feature that most python people don't > seem to know exists at all. > > I'm honestly worried about us expanding our use of them and would prefer > we got rid of our usage. I don't think the upcoming Pipfile stuff > supports them at all - and I believe that's on purpose.
Pipfile is being created as a replacement for requirements.txt but not in the way that we use the file. So it is possible to express via a Pipfile that something needs to install extras (see the example in https://github.com/pypa/pipfile) but it is not possible to express those extras there because that's not what that file is meant to be used for (as I think you've pointed out in the thread about pbr/pipfile integration). > > > Another idea was to add a 'all' extras that installed all of the more fine > > grained extra's options. That way a user can just say give me all the > > features I don't care even if I can't use them all I know the ones I can > > use will be properly installed. > > > > As for the CI jobs its just a matter of listing the extras in the > > appropriate requirements files or explicitly installing them. > > How about instead of extras we just make some additional packages? Like, > for instance make a "nova-zvm-support" repo that contains the extra > requirements in it and that we publish to PyPI. Then a user could do > "pip install nova nova-zvm-support" instead of "pip install nova[zvm]". So the driver would still live in the nova tree, but the dependencies for it would be expressed by a package that is built elsewhere? It feels like that's likely to require some extra care for ordering changes when a dependency has to be updated. > That way we can avoid installing optional things for the common case > when they're not going to be used (including in the gate where we have > no Z machines) but still provide a mechanism for users to easily install > the software they need. It would also let a 3rd-party ci that DOES have > some Z to test against to set up a zuul job that puts nova-zvm-support > into its required-projects and test the combination of the two. All of that is technically true. I'm not sure how a separate package is more discoverable than using extras, though. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
