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

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


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

Reply via email to