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

Joshua Harlow harlowja at fastmail.com
Tue Jan 12 00:33:35 UTC 2016


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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list