Open Stack

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