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.

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]".

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.

We could do a similar thing for the extras in keystoneauth. Make a keystoneauth-kerberos and a keystoneauth-saml2 and a keystoneauth-oauth1.

Just a thought...


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to