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