Dean Troyer wrote: > On Fri, Jan 9, 2015 at 4:22 AM, Thierry Carrez <thie...@openstack.org > <mailto:thie...@openstack.org>> wrote: > > This is probably a very dumb question, but could you explain why > keystoneclient.middleware can't map to keystonemiddleware functions > (adding keystonemiddleware as a dependency of future keystoneclient)? At > first glance that would allow to remove dead duplicated code while > ensuring compatibility for as long as we need to support those old > releases... > > Part of the reason for moving keystonemiddleware out of > keystonemiddleware was to do the reverse, have a keystoneclient install > NOT bring in auth_token. I doubt there will be anything other than > servers that need keystonemiddleware installed whereas quite a few > clients will not want it at all.
Sure, that should clearly still be the end goal... The idea would be to keep deprecated functions in the client lib until we consider those releases that need them truly dead. Not saying it's the best option ever, was just curious why it was not listed in the proposed options :) > I'm on the fence about changing stable requirements...if we imagine > keystonemiddleware is not an OpenStack project this wouldn't be the > first time we've had to do that when things change out from under us. > But I hate doing that to ourselves... This is not about changing "stable requirements": havana servers would still depend on "python-keystoneclient" like they always did. If you use an old version of that you are covered, and if you use a new version of that, *that* would pull keystonemiddleware as a new requirement. So this is about temporarily changing future keystoneclient requirements to avoid double maintenance of code while preserving compatibility. -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
