Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Victor Stinner]

Thanks for investigating the tabulate option :-)

Victor

Le 26/01/2016 02:25, Joshua Harlow a écrit :

As far as the other option (using tabulate):

https://bitbucket.org/astanin/python-tabulate/pull-requests/25/

That was a (very very basic) POC for a potential compatibility layer,

The author (of tabulate) though thinks that a
'tabulate-prettytable-compat' library might be the best option, which
seems to make sense. So if the jazzband thing doesn't work out we can
work with the tabulate author to create such a thing (and then as time
goes on just move to tabulate).

-Josh

Flavio Percoco wrote:

On 08/01/16 08:36 -0430, Flavio Percoco wrote:

Greetings,

As some of you know already, google code is going to be shutdown. Some
projects we're using are hosted and, unfortunately, some of them are
unmaintained and perhaps going away.

One of these projects is PrettyTable. This point was raised by Erno in
this patch[0] from jd__. PrettyTable is not just being used in several
openstack specific projects but it's also a transitive dependency for
all client libraries using cliff.

With all that in mind, I've contacted the author of the library and
asked him if it'd be ok for us (OpenStack) to adopt this library. The
author accepted and granted me access to the project on pypi.

I'm saying all the above because we now need to find a home for it in
OpenStack.

I've identified 2 possible places:

1) Oslo, as we maintaing cross-project libraries and some of them are
not in the oslo namespace

2) OpenStack Client team as they maintain cliff already and it'd
perhaps make more sense to have this library there.

One thing to note is that this library has been quite stable, which
means it won't, hopefully, add too much work to the team.

Thoughts?

[0] https://review.openstack.org/#/c/234340/


FWIW, we've decided to give jazzband[0] a try and host prettytable
there. If
that doesn't work out well, we might revisit this option (unless the
tabulate
migration happens before that).

[0] https://jazzband.co

Thanks everyone and Doug for suggesting jazzband!
Flavio



__


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



__

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


__
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


__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Joshua Harlow]

As far as the other option (using tabulate):

https://bitbucket.org/astanin/python-tabulate/pull-requests/25/

That was a (very very basic) POC for a potential compatibility layer,

The author (of tabulate) though thinks that a 
'tabulate-prettytable-compat' library might be the best option, which 
seems to make sense. So if the jazzband thing doesn't work out we can 
work with the tabulate author to create such a thing (and then as time 
goes on just move to tabulate).


-Josh

Flavio Percoco wrote:

On 08/01/16 08:36 -0430, Flavio Percoco wrote:

Greetings,

As some of you know already, google code is going to be shutdown. Some
projects we're using are hosted and, unfortunately, some of them are
unmaintained and perhaps going away.

One of these projects is PrettyTable. This point was raised by Erno in
this patch[0] from jd__. PrettyTable is not just being used in several
openstack specific projects but it's also a transitive dependency for
all client libraries using cliff.

With all that in mind, I've contacted the author of the library and
asked him if it'd be ok for us (OpenStack) to adopt this library. The
author accepted and granted me access to the project on pypi.

I'm saying all the above because we now need to find a home for it in
OpenStack.

I've identified 2 possible places:

1) Oslo, as we maintaing cross-project libraries and some of them are
not in the oslo namespace

2) OpenStack Client team as they maintain cliff already and it'd
perhaps make more sense to have this library there.

One thing to note is that this library has been quite stable, which
means it won't, hopefully, add too much work to the team.

Thoughts?

[0] https://review.openstack.org/#/c/234340/


FWIW, we've decided to give jazzband[0] a try and host prettytable
there. If
that doesn't work out well, we might revisit this option (unless the
tabulate
migration happens before that).

[0] https://jazzband.co

Thanks everyone and Doug for suggesting jazzband!
Flavio



__

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



__
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


__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Ruby Loo]

On 11 January 2016 at 10:27, Doug Hellmann  wrote:

> ...
>
>
> There are a few libraries on the list, too (automaton, ironic-lib), and
> that's confusing. It would be interesting to know how they're using
> table output.
>
> Doug
>
>
As far as ironic-lib goes, I took a look. It isn't using PrettyTable so out
it goes: https://review.openstack.org/267213.

Thanks for mentioning it Doug!

--ruby
__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Flavio Percoco]

On 08/01/16 08:36 -0430, Flavio Percoco wrote:

Greetings,

As some of you know already, google code is going to be shutdown. Some
projects we're using are hosted and, unfortunately, some of them are
unmaintained and perhaps going away.

One of these projects is PrettyTable. This point was raised by Erno in
this patch[0] from jd__. PrettyTable is not just being used in several
openstack specific projects but it's also a transitive dependency for
all client libraries using cliff.

With all that in mind, I've contacted the author of the library and
asked him if it'd be ok for us (OpenStack) to adopt this library. The
author accepted and granted me access to the project on pypi.

I'm saying all the above because we now need to find a home for it in
OpenStack.

I've identified 2 possible places:

1) Oslo, as we maintaing cross-project libraries and some of them are
not in the oslo namespace

2) OpenStack Client team as they maintain cliff already and it'd
perhaps make more sense to have this library there.

One thing to note is that this library has been quite stable, which
means it won't, hopefully, add too much work to the team.

Thoughts?

[0] https://review.openstack.org/#/c/234340/


FWIW, we've decided to give jazzband[0] a try and host prettytable there. If
that doesn't work out well, we might revisit this option (unless the tabulate
migration happens before that).

[0] https://jazzband.co

Thanks everyone and Doug for suggesting jazzband!
Flavio



__
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



--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Joshua Harlow]

Also using the fact that get_string() and __init__() of prettytable are 
the most complicated (both take kwargs that can tweak the behavior of 
the generated results) and that most projects (see below) don't seem to 
be customizing the behavior (that much) it makes me thing its safer to 
provide a basic compat/option translation layer and move on.


Here is the analysis of the following projects usage of it:

automaton
cliff
cloudv-ostf-adapter
distil
faafo
fairy-slipper
gnocchi
ironic-lib
kolla-mesos
magnum
nova
openstack-ansible
rally
requirements
sahara
scalpels
stacktach-klugman
vmtp
vmware-nsx

Grep/tiny-crappy-script result:

http://paste.openstack.org/show/483512/

The case that sticks out is:

./nova/openstack/common/cliutils.py (or other usages of cliutils).

print(encodeutils.safe_encode(pt.get_string(**kwargs)))

That allows arbitrary kwargs so unknown how that will work (requires 
more analysis to figure out really what those kwargs are).


The rest seem like they could be accommodated by something like (with 
some minor additions to do sorting for example):


https://bitbucket.org/astanin/python-tabulate/pull-requests/25/

-Josh

Doug Hellmann wrote:

Excerpts from Victor Stinner's message of 2016-01-11 11:15:56 +0100:

Le 11/01/2016 10:37, Thierry Carrez a écrit :

Joshua Harlow wrote:

[...]
So I'd def help keep prettytable going, of course another option is to
move to https://pypi.python.org/pypi/tabulate (which does seem active
and/or maintained); tabulate provides pretty much the same thing
(actually more table formats @
https://pypi.python.org/pypi/tabulate#table-format ) than prettytable
and the api is pretty much the same (or nearly).

So that's another way to handle this (just to move off prettytable
entirely).

This sounds like a reasonable alternative...


IMHO contributing to an actively developped library (tabulate) seems
more productive than starting to maintain a second library which is
currently no more maintained.

Does anyone know how much code should be modified to replace prettytable
with tabulate on the whole OpenStack project?


We seem to have a rather long list of things consuming PrettyTable:

$ grep -i prettytable */*requirement*.txt
automaton/requirements.txt:PrettyTable<0.8,>=0.7
cliff/requirements.txt:PrettyTable<0.8,>=0.7
cloudv-ostf-adapter/requirements.txt:PrettyTable>=0.7,<0.8
distil/requirements.txt:prettytable==0.7.2
faafo/requirements.txt:PrettyTable>=0.7,<0.8
fairy-slipper/requirements.txt:prettytable
gnocchi/requirements.txt:prettytable
ironic-lib/requirements.txt:PrettyTable<0.8,>=0.7
kolla-mesos/requirements.txt:PrettyTable<0.8,>=0.7
magnum/requirements.txt:PrettyTable<0.8,>=0.7
nova/requirements.txt:PrettyTable<0.8,>=0.7
openstack-ansible/requirements.txt:PrettyTable>=0.7,<0.8   # 
scripts/inventory-manage.py
python-blazarclient/requirements.txt:PrettyTable>=0.7,<0.8
python-ceilometerclient/requirements.txt:PrettyTable<0.8,>=0.7
python-cinderclient/requirements.txt:PrettyTable<0.8,>=0.7
python-evoqueclient/requirements.txt:PrettyTable<0.8,>=0.7
python-glanceclient/requirements.txt:PrettyTable<0.8,>=0.7
python-heatclient/requirements.txt:PrettyTable<0.8,>=0.7
python-ironicclient/requirements.txt:PrettyTable<0.8,>=0.7
python-keystoneclient/requirements.txt:PrettyTable<0.8,>=0.7
python-magnumclient/requirements.txt:PrettyTable<0.8,>=0.7
python-manilaclient/requirements.txt:PrettyTable<0.8,>=0.7
python-monascaclient/requirements.txt:PrettyTable>=0.7,<0.8
python-muranoclient/requirements.txt:PrettyTable<0.8,>=0.7
python-novaclient/requirements.txt:PrettyTable<0.8,>=0.7
python-rackclient/requirements.txt:PrettyTable>=0.7,<0.8
python-saharaclient/requirements.txt:PrettyTable<0.8,>=0.7
python-searchlightclient/requirements.txt:PrettyTable<0.8,>=0.7
python-senlinclient/requirements.txt:PrettyTable<0.8,>=0.7
python-surveilclient/requirements.txt:prettytable
python-troveclient/requirements.txt:PrettyTable<0.8,>=0.7
python-tuskarclient/requirements.txt:PrettyTable<0.8,>=0.7
rally/requirements.txt:PrettyTable<0.8,>=0.7
requirements/global-requirements.txt:PrettyTable>=0.7,<0.8
sahara/test-requirements.txt:PrettyTable<0.8,>=0.7
scalpels/requirements.txt:PrettyTable>=0.7,<0.8
stacktach-klugman/requirements.txt:prettytable
vmtp/requirements.txt:prettytable>=0.7.2
vmware-nsx/requirements.txt:PrettyTable<0.8,>=0.7

I suspect we could skip porting a lot of those, since they look like
clients and we're working to move all command line programs into the
unified client.

That leaves 18:

$ grep -i prettytable */*requirement*.txt | grep -v client
automaton/requirements.txt:PrettyTable<0.8,>=0.7
cliff/requirements.txt:PrettyTable<0.8,>=0.7
cloudv-ostf-adapter/requirements.txt:PrettyTable>=0.7,<0.8
distil/requirements.txt:prettytable==0.7.2
faafo/requirements.txt:PrettyTable>=0.7,<0.8
fairy-slipper/requirements.txt:prettytable
gnocchi/requirements.txt:prettytable
ironic-lib/requirements.txt:PrettyTable<0.8,>=0.7
kolla-mesos/requirements.txt:PrettyTable<0.8,>=0.7

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Victor Stinner]

Le 11/01/2016 10:37, Thierry Carrez a écrit :

Joshua Harlow wrote:

[...]
So I'd def help keep prettytable going, of course another option is to
move to https://pypi.python.org/pypi/tabulate (which does seem active
and/or maintained); tabulate provides pretty much the same thing
(actually more table formats @
https://pypi.python.org/pypi/tabulate#table-format ) than prettytable
and the api is pretty much the same (or nearly).

So that's another way to handle this (just to move off prettytable
entirely).


This sounds like a reasonable alternative...



IMHO contributing to an actively developped library (tabulate) seems 
more productive than starting to maintain a second library which is 
currently no more maintained.


Does anyone know how much code should be modified to replace prettytable 
with tabulate on the whole OpenStack project?


--

I don't like the global trend in OpenStack to create a new community 
separated from the Python community. In general, OpenStack libraries 
have too many dependencies and it's harder to contribute to other 
projects. Gerrit is less popular than Github, and OpenStack requires to 
sign a contributor agreement. I would prefer to stop moving things into 
OpenStack and continue to contribute to existing projects, as we already do.


(I also know why projects are moved into OpenStack "big tent", they are 
some good arguments.)


Well, that's my feeling that OpenStack and Python communities are 
splitted, maybe I'm wrong ;-) I just want to avoid what happened in 
Zope: a lot of great code and great libraries, but too many dependencies 
and at the end a different community.


Victor

__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Thierry Carrez]

Joshua Harlow wrote:

[...]
So I'd def help keep prettytable going, of course another option is to
move to https://pypi.python.org/pypi/tabulate (which does seem active
and/or maintained); tabulate provides pretty much the same thing
(actually more table formats @
https://pypi.python.org/pypi/tabulate#table-format ) than prettytable
and the api is pretty much the same (or nearly).

So that's another way to handle this (just to move off prettytable
entirely).


This sounds like a reasonable alternative...

--
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Doug Hellmann]

Excerpts from Victor Stinner's message of 2016-01-11 11:15:56 +0100:
> Le 11/01/2016 10:37, Thierry Carrez a écrit :
> > Joshua Harlow wrote:
> >> [...]
> >> So I'd def help keep prettytable going, of course another option is to
> >> move to https://pypi.python.org/pypi/tabulate (which does seem active
> >> and/or maintained); tabulate provides pretty much the same thing
> >> (actually more table formats @
> >> https://pypi.python.org/pypi/tabulate#table-format ) than prettytable
> >> and the api is pretty much the same (or nearly).
> >>
> >> So that's another way to handle this (just to move off prettytable
> >> entirely).
> >
> > This sounds like a reasonable alternative...
> 
> 
> IMHO contributing to an actively developped library (tabulate) seems 
> more productive than starting to maintain a second library which is 
> currently no more maintained.
> 
> Does anyone know how much code should be modified to replace prettytable 
> with tabulate on the whole OpenStack project?

We seem to have a rather long list of things consuming PrettyTable:

$ grep -i prettytable */*requirement*.txt
automaton/requirements.txt:PrettyTable<0.8,>=0.7
cliff/requirements.txt:PrettyTable<0.8,>=0.7
cloudv-ostf-adapter/requirements.txt:PrettyTable>=0.7,<0.8
distil/requirements.txt:prettytable==0.7.2
faafo/requirements.txt:PrettyTable>=0.7,<0.8
fairy-slipper/requirements.txt:prettytable
gnocchi/requirements.txt:prettytable
ironic-lib/requirements.txt:PrettyTable<0.8,>=0.7
kolla-mesos/requirements.txt:PrettyTable<0.8,>=0.7
magnum/requirements.txt:PrettyTable<0.8,>=0.7
nova/requirements.txt:PrettyTable<0.8,>=0.7
openstack-ansible/requirements.txt:PrettyTable>=0.7,<0.8   # 
scripts/inventory-manage.py
python-blazarclient/requirements.txt:PrettyTable>=0.7,<0.8
python-ceilometerclient/requirements.txt:PrettyTable<0.8,>=0.7
python-cinderclient/requirements.txt:PrettyTable<0.8,>=0.7
python-evoqueclient/requirements.txt:PrettyTable<0.8,>=0.7
python-glanceclient/requirements.txt:PrettyTable<0.8,>=0.7
python-heatclient/requirements.txt:PrettyTable<0.8,>=0.7
python-ironicclient/requirements.txt:PrettyTable<0.8,>=0.7
python-keystoneclient/requirements.txt:PrettyTable<0.8,>=0.7
python-magnumclient/requirements.txt:PrettyTable<0.8,>=0.7
python-manilaclient/requirements.txt:PrettyTable<0.8,>=0.7
python-monascaclient/requirements.txt:PrettyTable>=0.7,<0.8
python-muranoclient/requirements.txt:PrettyTable<0.8,>=0.7
python-novaclient/requirements.txt:PrettyTable<0.8,>=0.7
python-rackclient/requirements.txt:PrettyTable>=0.7,<0.8
python-saharaclient/requirements.txt:PrettyTable<0.8,>=0.7
python-searchlightclient/requirements.txt:PrettyTable<0.8,>=0.7
python-senlinclient/requirements.txt:PrettyTable<0.8,>=0.7
python-surveilclient/requirements.txt:prettytable
python-troveclient/requirements.txt:PrettyTable<0.8,>=0.7
python-tuskarclient/requirements.txt:PrettyTable<0.8,>=0.7
rally/requirements.txt:PrettyTable<0.8,>=0.7
requirements/global-requirements.txt:PrettyTable>=0.7,<0.8
sahara/test-requirements.txt:PrettyTable<0.8,>=0.7
scalpels/requirements.txt:PrettyTable>=0.7,<0.8
stacktach-klugman/requirements.txt:prettytable
vmtp/requirements.txt:prettytable>=0.7.2
vmware-nsx/requirements.txt:PrettyTable<0.8,>=0.7

I suspect we could skip porting a lot of those, since they look like
clients and we're working to move all command line programs into the
unified client.

That leaves 18:

$ grep -i prettytable */*requirement*.txt | grep -v client
automaton/requirements.txt:PrettyTable<0.8,>=0.7
cliff/requirements.txt:PrettyTable<0.8,>=0.7
cloudv-ostf-adapter/requirements.txt:PrettyTable>=0.7,<0.8
distil/requirements.txt:prettytable==0.7.2
faafo/requirements.txt:PrettyTable>=0.7,<0.8
fairy-slipper/requirements.txt:prettytable
gnocchi/requirements.txt:prettytable
ironic-lib/requirements.txt:PrettyTable<0.8,>=0.7
kolla-mesos/requirements.txt:PrettyTable<0.8,>=0.7
magnum/requirements.txt:PrettyTable<0.8,>=0.7
nova/requirements.txt:PrettyTable<0.8,>=0.7
openstack-ansible/requirements.txt:PrettyTable>=0.7,<0.8   # 
scripts/inventory-manage.py
rally/requirements.txt:PrettyTable<0.8,>=0.7
requirements/global-requirements.txt:PrettyTable>=0.7,<0.8
sahara/test-requirements.txt:PrettyTable<0.8,>=0.7
scalpels/requirements.txt:PrettyTable>=0.7,<0.8
stacktach-klugman/requirements.txt:prettytable
vmtp/requirements.txt:prettytable>=0.7.2
vmware-nsx/requirements.txt:PrettyTable<0.8,>=0.7

There are a few server projects, and I assume they are using the
lib in their management commands.  I'm sure there are shell scripts
out there parsing the rendered tables.  Does tabulate produce tables
using the exact same format as PrettyTable?

We could justify moving cliff, since it makes it easy to produce
more parsable output using selectable formatters, but some of those
other consuming projects may be a bit harder to change if we want
to maintain our backwards compatibility requirements.

There are a few libraries on the list, too (automaton, ironic-lib), and
that's confusing. It 

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Flavio Percoco]

On 11/01/16 11:15 +0100, Victor Stinner wrote:

Le 11/01/2016 10:37, Thierry Carrez a écrit :

Joshua Harlow wrote:

[...]
So I'd def help keep prettytable going, of course another option is to
move to https://pypi.python.org/pypi/tabulate (which does seem active
and/or maintained); tabulate provides pretty much the same thing
(actually more table formats @
https://pypi.python.org/pypi/tabulate#table-format ) than prettytable
and the api is pretty much the same (or nearly).

So that's another way to handle this (just to move off prettytable
entirely).


This sounds like a reasonable alternative...



IMHO contributing to an actively developped library (tabulate) seems 
more productive than starting to maintain a second library which is 
currently no more maintained.


Does anyone know how much code should be modified to replace 
prettytable with tabulate on the whole OpenStack project?


--

I don't like the global trend in OpenStack to create a new community 
separated from the Python community. In general, OpenStack libraries 
have too many dependencies and it's harder to contribute to other 
projects. Gerrit is less popular than Github, and OpenStack requires 
to sign a contributor agreement. I would prefer to stop moving things 
into OpenStack and continue to contribute to existing projects, as we 
already do.


I wouldn't see this as "OpenStack just likes to create new communities
because why not?". IMHO, the fact the OpenStack community is willing
to take on libraries and help maintaining them is a good example of
good open source behavior. We use the library, the original author
doesn't have time and we have resources to help.

We are not the ones using this library and this is the way we have to
contribute to it. We're giving the library a home. If someone is
willing to take the library on outside of OpenStack, then fine. I'm
all for that. I just don't have the time myself.

That said, I also think consuming tabulate would be a good solution
but again, I don't have time to help with the migration. Therefore,
until that happens, I'm concerned that we don't have a way to fix bugs
and contribute to the current library we're using, which is
prettytable.

If the switch happens and we all pass to tabulate, then we can
re-evaluate whether keeping prettytable under the OpenStack tent makes
sense.

Flavio

(I also know why projects are moved into OpenStack "big tent", they 
are some good arguments.)


Well, that's my feeling that OpenStack and Python communities are 
splitted, maybe I'm wrong ;-) I just want to avoid what happened in 
Zope: a lot of great code and great libraries, but too many 
dependencies and at the end a different community.


Victor

__
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


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Julien Danjou]

On Mon, Jan 11 2016, Doug Hellmann wrote:

> I suspect we could skip porting a lot of those, since they look like
> clients and we're working to move all command line programs into the
> unified client.

Not really in the telemetry roadmap honestly. But we could move away
From prettytable without much burden anyway.

> There are a few server projects, and I assume they are using the
> lib in their management commands.  I'm sure there are shell scripts
> out there parsing the rendered tables.  Does tabulate produce tables
> using the exact same format as PrettyTable?

We barely use it in Gnocchi, it could be easy to switch to something
fancier. Back then, we just picked PrettyTable because every other
project was using it and it was good enough for a quick CLI.

> We could justify moving cliff, since it makes it easy to produce
> more parsable output using selectable formatters, but some of those
> other consuming projects may be a bit harder to change if we want
> to maintain our backwards compatibility requirements.

I think that's a good idea, gnocchiclient and aodhclient already rely on
cliff for example, and ceilometerclient should switch at some point.

> There are a few libraries on the list, too (automaton, ironic-lib), and
> that's confusing. It would be interesting to know how they're using
> table output.

automaton uses it for its verbose mode, it's just 2 lines to change… :)

Cheers,
-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Joshua Harlow]

And here is a simple converter that uses tabulate but has somewhat like 
the pretty table object format that people are used to (could be away to 
get 90% of the common usage over to tabulate, minus the special 
prettytable users that are doing advanced things).


https://gist.github.com/harlowja/d5f4824b4ce0ea95530c

The grid output/format of tabulate seems to be pretty close to what 
prettytable output/format is (but my guess is there is some variation, 
just because of different authors/codebases...)


-Josh

Julien Danjou wrote:

On Mon, Jan 11 2016, Doug Hellmann wrote:


I suspect we could skip porting a lot of those, since they look like
clients and we're working to move all command line programs into the
unified client.


Not really in the telemetry roadmap honestly. But we could move away
 From prettytable without much burden anyway.


There are a few server projects, and I assume they are using the
lib in their management commands.  I'm sure there are shell scripts
out there parsing the rendered tables.  Does tabulate produce tables
using the exact same format as PrettyTable?


We barely use it in Gnocchi, it could be easy to switch to something
fancier. Back then, we just picked PrettyTable because every other
project was using it and it was good enough for a quick CLI.


We could justify moving cliff, since it makes it easy to produce
more parsable output using selectable formatters, but some of those
other consuming projects may be a bit harder to change if we want
to maintain our backwards compatibility requirements.


I think that's a good idea, gnocchiclient and aodhclient already rely on
cliff for example, and ceilometerclient should switch at some point.


There are a few libraries on the list, too (automaton, ironic-lib), and
that's confusing. It would be interesting to know how they're using
table output.


automaton uses it for its verbose mode, it's just 2 lines to change… :)

Cheers,

__
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


__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Joshua Harlow]

Julien Danjou wrote:

On Mon, Jan 11 2016, Doug Hellmann wrote:


I suspect we could skip porting a lot of those, since they look like
clients and we're working to move all command line programs into the
unified client.


Not really in the telemetry roadmap honestly. But we could move away
 From prettytable without much burden anyway.


There are a few server projects, and I assume they are using the
lib in their management commands.  I'm sure there are shell scripts
out there parsing the rendered tables.  Does tabulate produce tables
using the exact same format as PrettyTable?


We barely use it in Gnocchi, it could be easy to switch to something
fancier. Back then, we just picked PrettyTable because every other
project was using it and it was good enough for a quick CLI.


We could justify moving cliff, since it makes it easy to produce
more parsable output using selectable formatters, but some of those
other consuming projects may be a bit harder to change if we want
to maintain our backwards compatibility requirements.


I think that's a good idea, gnocchiclient and aodhclient already rely on
cliff for example, and ceilometerclient should switch at some point.


There are a few libraries on the list, too (automaton, ironic-lib), and
that's confusing. It would be interesting to know how they're using
table output.


automaton uses it for its verbose mode, it's just 2 lines to change… :)


Right the table output at the 'expected output' of str(machine) or see 
http://docs.openstack.org/developer/automaton/examples.html#creating-a-complex-cd-player-machine 
(for an example) is where prettytable is used, nothing fancy though, can 
be tabulate with a few line change...




Cheers,

__
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


__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Joshua Harlow]

Victor Stinner wrote:

Le 11/01/2016 10:37, Thierry Carrez a écrit :

Joshua Harlow wrote:

[...]
So I'd def help keep prettytable going, of course another option is to
move to https://pypi.python.org/pypi/tabulate (which does seem active
and/or maintained); tabulate provides pretty much the same thing
(actually more table formats @
https://pypi.python.org/pypi/tabulate#table-format ) than prettytable
and the api is pretty much the same (or nearly).

So that's another way to handle this (just to move off prettytable
entirely).


This sounds like a reasonable alternative...



IMHO contributing to an actively developped library (tabulate) seems
more productive than starting to maintain a second library which is
currently no more maintained.

Does anyone know how much code should be modified to replace prettytable
with tabulate on the whole OpenStack project?

--

I don't like the global trend in OpenStack to create a new community
separated from the Python community. In general, OpenStack libraries
have too many dependencies and it's harder to contribute to other
projects. Gerrit is less popular than Github, and OpenStack requires to
sign a contributor agreement. I would prefer to stop moving things into
OpenStack and continue to contribute to existing projects, as we already
do.

(I also know why projects are moved into OpenStack "big tent", they are
some good arguments.)

Well, that's my feeling that OpenStack and Python communities are
splitted, maybe I'm wrong ;-) I just want to avoid what happened in
Zope: a lot of great code and great libraries, but too many dependencies
and at the end a different community.


It's always going to be a constant back and forth IMHO, but I hope it 
doesn't split (as u say), in fact I think we can work together better 
IMHO, perhaps openstack can help prototype/test your new 
https://faster-cpython.readthedocs.org/ work for example. That might 
actually help reduce the split (and is something that both communities 
could benefit from)?


Of course what's needed IMHO is more folks focusing on the shared 
cross-project issues and helping resolve them; that's part of the 
eternal back and forth (inside of openstack) is vendors focusing on 
single/a few projects but a limited number of people looking across 
projects and trying to see (and work-through/solve) the bigger issues 
there... But I also start to believe this is just the nature of the game 
and it may never be what I would like it to be (where a larger group of 
people work across projects, vs inside of one/two/a few)...




Victor

__
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


__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Joshua Harlow]

I'm fine with #2 or #1

The oslo automaton lib also uses pretty table to generate state-machine 
tables (a useful feature to have, but not a necessity).


https://github.com/openstack/automaton/blob/master/requirements.txt#L14

So I'd def help keep prettytable going, of course another option is to 
move to https://pypi.python.org/pypi/tabulate (which does seem active 
and/or maintained); tabulate provides pretty much the same thing 
(actually more table formats @ 
https://pypi.python.org/pypi/tabulate#table-format ) than prettytable 
and the api is pretty much the same (or nearly).


So that's another way to handle this (just to move off prettytable 
entirely).


-Josh

Davanum Srinivas wrote:

#2 please :)

Thanks,
Dims

On Fri, Jan 8, 2016 at 8:06 AM, Flavio Percoco  wrote:

Greetings,

As some of you know already, google code is going to be shutdown. Some
projects we're using are hosted and, unfortunately, some of them are
unmaintained and perhaps going away.

One of these projects is PrettyTable. This point was raised by Erno in
this patch[0] from jd__. PrettyTable is not just being used in several
openstack specific projects but it's also a transitive dependency for
all client libraries using cliff.

With all that in mind, I've contacted the author of the library and
asked him if it'd be ok for us (OpenStack) to adopt this library. The
author accepted and granted me access to the project on pypi.

I'm saying all the above because we now need to find a home for it in
OpenStack.

I've identified 2 possible places:

1) Oslo, as we maintaing cross-project libraries and some of them are
not in the oslo namespace

2) OpenStack Client team as they maintain cliff already and it'd
perhaps make more sense to have this library there.

One thing to note is that this library has been quite stable, which
means it won't, hopefully, add too much work to the team.

Thoughts?

[0] https://review.openstack.org/#/c/234340/

--
@flaper87
Flavio Percoco

__
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







__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/08/2016 07:06 AM, Flavio Percoco wrote:
> I'm saying all the above because we now need to find a home for it in
> OpenStack.
> 
> I've identified 2 possible places:
> 
> 1) Oslo, as we maintaing cross-project libraries and some of them are
> not in the oslo namespace
> 
> 2) OpenStack Client team as they maintain cliff already and it'd
> perhaps make more sense to have this library there.

#2 makes the most sense to me.  Thanks for taking action to keep PrettyTable 
alive! :)

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWj7taAAoJEHNwUeDBAR+xBPkP/2HPChBdroQH/bW9l1LfEvxR
KzkJa8GeMMjs5nhc55AttR6H8lOyp+f2sj0+3lcSV/9AmWdK0+TN+KcZTHhWHYqM
ONMVN6ii4tAvwN48lJALHxr02D+iPEH6HWw3iH5sMfnoQfoDNSQM6m42XWtHP0GR
cGlYr3M2lPXJbpEiDqJHLWBWWbHeuy5wCyZpcJY4GNNZUcv9Xm+XT3s+bE27tFhm
mVYZRgBbxfHHhNaaEkI5e9n6DSmFc5ScJU94O3lSNPP439pDxHHVVODwDnJXhKHx
dAAE7wxFpJEYrYKFJNDK8g48qKKXevqrUVDhnAKW8ivsDENDYhwdqJ3U0p0i6cCj
qeScjSqCwzjbVxibj89YtcosstkDZgyASIfp99MRQ9/TxsO9vqa9wi8O/WQsljbY
y0WwFRXQkpcndE6Ia/t1uu7EaXmUbtPsVldMKwdUpelr/b/R0F/T6Z503rG83Dy1
FLvVxqDk3Leb4VV/H6zNNqKm9mcw1hB7JfDcEDRR7HarEA/p8HZezlCXg9Fa0w7x
ZngtPO9/23g35Bk62XqU01yy7d6OmBpCsGMXcjsmyWojhF7VIjZCvWlY2BK5+tUQ
IkdMgXXS6AIyXBef89sRxZ/48Nw6ZyYkepiKUoSVztvQzqNOOhKHBFd+9visC9De
+tjioMLJ3V2QO8qszGrs
=wUJt
-END PGP SIGNATURE-

__
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

[openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Flavio Percoco]

Greetings,

As some of you know already, google code is going to be shutdown. Some
projects we're using are hosted and, unfortunately, some of them are
unmaintained and perhaps going away.

One of these projects is PrettyTable. This point was raised by Erno in
this patch[0] from jd__. PrettyTable is not just being used in several
openstack specific projects but it's also a transitive dependency for
all client libraries using cliff.

With all that in mind, I've contacted the author of the library and
asked him if it'd be ok for us (OpenStack) to adopt this library. The
author accepted and granted me access to the project on pypi.

I'm saying all the above because we now need to find a home for it in
OpenStack.

I've identified 2 possible places:

1) Oslo, as we maintaing cross-project libraries and some of them are
not in the oslo namespace

2) OpenStack Client team as they maintain cliff already and it'd
perhaps make more sense to have this library there.

One thing to note is that this library has been quite stable, which
means it won't, hopefully, add too much work to the team.

Thoughts?

[0] https://review.openstack.org/#/c/234340/

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Davanum Srinivas]

#2 please :)

Thanks,
Dims

On Fri, Jan 8, 2016 at 8:06 AM, Flavio Percoco  wrote:
> Greetings,
>
> As some of you know already, google code is going to be shutdown. Some
> projects we're using are hosted and, unfortunately, some of them are
> unmaintained and perhaps going away.
>
> One of these projects is PrettyTable. This point was raised by Erno in
> this patch[0] from jd__. PrettyTable is not just being used in several
> openstack specific projects but it's also a transitive dependency for
> all client libraries using cliff.
>
> With all that in mind, I've contacted the author of the library and
> asked him if it'd be ok for us (OpenStack) to adopt this library. The
> author accepted and granted me access to the project on pypi.
>
> I'm saying all the above because we now need to find a home for it in
> OpenStack.
>
> I've identified 2 possible places:
>
> 1) Oslo, as we maintaing cross-project libraries and some of them are
> not in the oslo namespace
>
> 2) OpenStack Client team as they maintain cliff already and it'd
> perhaps make more sense to have this library there.
>
> One thing to note is that this library has been quite stable, which
> means it won't, hopefully, add too much work to the team.
>
> Thoughts?
>
> [0] https://review.openstack.org/#/c/234340/
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Doug Hellmann]

Excerpts from Dean Troyer's message of 2016-01-08 09:56:53 -0600:
> On Fri, Jan 8, 2016 at 7:06 AM, Flavio Percoco  wrote:
> 
> > 2) OpenStack Client team as they maintain cliff already and it'd
> > perhaps make more sense to have this library there.
> >
> 
> I would support this as we already have os-client-config as well as cliff.
> I would love to be able to identify some folks who can commit some time for
> a transition and initial core team.

+1 -- we've definitely proven that teams other than Oslo can manage
shared libraries, so if the OSC team is prepared to adopt it that would
be a good home.

> 
> > One thing to note is that this library has been quite stable, which
> > means it won't, hopefully, add too much work to the team.
> >
> 
> This would actually solve a pain point we have had a couple of times in the
> past when PrettyTable changes broke us unexpectedly.  The recent stability
> is encouraging.
> 
> dt
> 

__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Ghe Rivero]

#2 makes more sense.

Ghe Rivero

Quoting Flavio Percoco (2016-01-08 14:06:28)
> Greetings,
>
> As some of you know already, google code is going to be shutdown. Some
> projects we're using are hosted and, unfortunately, some of them are
> unmaintained and perhaps going away.
>
> One of these projects is PrettyTable. This point was raised by Erno in
> this patch[0] from jd__. PrettyTable is not just being used in several
> openstack specific projects but it's also a transitive dependency for
> all client libraries using cliff.
>
> With all that in mind, I've contacted the author of the library and
> asked him if it'd be ok for us (OpenStack) to adopt this library. The
> author accepted and granted me access to the project on pypi.
>
> I'm saying all the above because we now need to find a home for it in
> OpenStack.
>
> I've identified 2 possible places:
>
> 1) Oslo, as we maintaing cross-project libraries and some of them are
> not in the oslo namespace
>
> 2) OpenStack Client team as they maintain cliff already and it'd
> perhaps make more sense to have this library there.
>
> One thing to note is that this library has been quite stable, which
> means it won't, hopefully, add too much work to the team.
>
> Thoughts?
>
> [0] https://review.openstack.org/#/c/234340/
>
> --
> @flaper87
> Flavio Percoco
>
>
> __
> 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

__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Flavio Percoco]

On 08/01/16 08:36 -0430, Flavio Percoco wrote:

Greetings,

As some of you know already, google code is going to be shutdown. Some
projects we're using are hosted and, unfortunately, some of them are
unmaintained and perhaps going away.

One of these projects is PrettyTable. This point was raised by Erno in
this patch[0] from jd__. PrettyTable is not just being used in several
openstack specific projects but it's also a transitive dependency for
all client libraries using cliff.

With all that in mind, I've contacted the author of the library and
asked him if it'd be ok for us (OpenStack) to adopt this library. The
author accepted and granted me access to the project on pypi.

I'm saying all the above because we now need to find a home for it in
OpenStack.

I've identified 2 possible places:

1) Oslo, as we maintaing cross-project libraries and some of them are
not in the oslo namespace

2) OpenStack Client team as they maintain cliff already and it'd
perhaps make more sense to have this library there.

One thing to note is that this library has been quite stable, which
means it won't, hopefully, add too much work to the team.

Thoughts?


Thank you all for the feedback! Here are the 2 patches proposing the
addition of prettytable into OpenStack.

- https://review.openstack.org/#/c/265278/
- https://review.openstack.org/#/c/265344/

Cheers,
Flavio



[0] https://review.openstack.org/#/c/234340/

--
@flaper87
Flavio Percoco





__
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



--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

[Dean Troyer]

On Fri, Jan 8, 2016 at 7:06 AM, Flavio Percoco  wrote:

> 2) OpenStack Client team as they maintain cliff already and it'd
> perhaps make more sense to have this library there.
>

I would support this as we already have os-client-config as well as cliff.
I would love to be able to identify some folks who can commit some time for
a transition and initial core team.


> One thing to note is that this library has been quite stable, which
> means it won't, hopefully, add too much work to the team.
>

This would actually solve a pain point we have had a couple of times in the
past when PrettyTable changes broke us unexpectedly.  The recent stability
is encouraging.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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