Open Stack

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

Monty