Cool. I have no objections.
On Jun 25, 2014 9:27 AM, "Dmitriy Shulyak" wrote:
> As i mentioned cliff uses similar approach, extending app by means of
> entry points, and written by same author.
> So i think stevedore will be used in cliff, or maybe already used in newer
> versions.
> But apart of
As i mentioned cliff uses similar approach, extending app by means of entry
points, and written by same author.
So i think stevedore will be used in cliff, or maybe already used in newer
versions.
But apart of stevedore-like dynamic extensions - cliff provides modular
layers for cli app, it is kind
Why not to use stevedore?
On Wed, Jun 18, 2014 at 1:42 PM, Igor Kalnitsky
wrote:
> Hi guys,
>
> Actually, I'm not a fun of cliff, but I think it's a good solution to use
> it in our fuel client.
>
> Here some pros:
>
> * pluggable design: we can encapsulate entire command logic in separate
> pl
Hi guys,
Actually, I'm not a fun of cliff, but I think it's a good solution to use
it in our fuel client.
Here some pros:
* pluggable design: we can encapsulate entire command logic in separate
plugin file
* builtin output formatters: we no need to implement various formatters to
represent recei
Hi folks,
I am wondering what our story/vision for plugins in fuel client [1]?
We can benefit from using cliff [2] as framework for fuel cli, apart from
common code
for building cli applications on top of argparse, it provides nice feature
that allows to
dynamicly add actions by means of entry po
