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
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 would be interesting to know how they're using
table output.

Doug

--

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

__________________________________________________________________________
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

Reply via email to