[openstack-dev] [mistral][osc-lib][openstackclient] is it too early for orc-lib?
Renat Akhmerov
renat.akhmerov at gmail.com
Mon Jul 4 06:17:11 UTC 2016
Ok, based on what has been said here I suggest we keep this code for now. The changes were really minimal. If it creates some problems for us we can always easily revert.
Renat Akhmerov
@Nokia
> On 01 Jul 2016, at 04:57, Steve Martinelli <s.martinelli at gmail.com> wrote:
>
> The crux of this, as Dean stated, is if the library wants OSC to always be pulled in (along with its many dependencies). We've seen folks include it in requirements, test-requirements, or even not at all (just document that OSC needs to be installed).
>
> I tossed up the idea with the ironic team of leveraging "extras" field to list OSC as optional, the change would look like:
>
> --- a/setup.cfg
> +++ b/setup.cfg
> @@ -22,6 +22,10 @@ classifier =
>
> +[extras]
> +cli =
> + python-openstackclient>=3.0.0 # Apache-2.0
> +
>
> So, if a user wanted to install just the python binding of ironicclient or mistralclient, they would do $ pip install python-ironicclient; if a user wanted the CLI as well.. $ pip install python-ironicclient[cli]
>
> Just an idea, it may be overkill and completely horrible.
>
> On Thu, Jun 30, 2016 at 5:29 PM, Dean Troyer <dtroyer at gmail.com <mailto:dtroyer at gmail.com>> wrote:
> On Thu, Jun 30, 2016 at 8:38 AM, Hardik <hardik.parekh at nectechnologies.in <mailto:hardik.parekh at nectechnologies.in>> wrote:
> Regarding osc-lib we have mainly two changes.
>
> 1) Used "utils" which is moved from openstackclient.common.utils to osc_lib.utils
> 2) We used "command" which wrapped in osc_lib from cliff.
>
> So I think there is no harm in keeping osc_lib.
>
> Admittedly the change to include osc-lib is a little early, I would have preferred until the other parts of it were a bit more stable.
>
> Also, I guess we do not need openstackclient to be installed with mistralclient as if mistral is used in standalone mode
> there is no need of openstackclient.
>
> The choice to include OSC as a dependency of a plugin/library rests entirely on the plugin team, and that will usually be determined by the answer to the question "Do you want all users of your library to have OSc installed even if they do not use it?" or alternatively "Do you want to make your users remember to install OSC after installing the plugin?"
>
> Note that we do intend to have the capability on osc-lib to build an OSC-like stand-alone binary for plugins that would theoretically make installing OSC optional for stand-alone client users. This is not complete yet, and as I said above, one reason I wish osc-lib had not been merged into plugin requirements yet. That said, as long as you don't use those bits yet you will be fine, the utils, command, etc bits are stable, it is the clientmanager and shell parts that are still being developed.
>
> dt
>
> --
>
> Dean Troyer
> dtroyer at gmail.com <mailto:dtroyer at gmail.com>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b0a28ef7/attachment.html>
More information about the OpenStack-dev
mailing list