cliff 3.10.1 release

meta:version: 3.10.1
meta:diff-start: -
meta:series: yoga
meta:release-type: release
meta:pypi: yes
meta:first: no
meta:release:Author: Daniel Bengtsson <dbengt@redhat.com>
meta:release:Commit: Daniel Bengtsson <dbengt@redhat.com>
meta:release:Change-Id: I4b884e661ec22523ec78519b85c035563de388df
meta:release:Code-Review+2: Elod Illes <elod.illes@est.tech>
meta:release:Workflow+1: Elod Illes <elod.illes@est.tech>

cliff 3.10.0 release

meta:version: 3.10.0
meta:diff-start: -
meta:series: yoga
meta:release-type: release
meta:pypi: yes
meta:first: yes
meta:release:Author: Elod Illes <elod.illes@est.tech>
meta:release:Commit: Elod Illes <elod.illes@est.tech>
meta:release:Change-Id: Id39f81270d996cbcf0d4a3d37b3042309cd456b9
meta:release:Code-Review+2: Hervé Beraud <herveberaud.pro@gmail.com>
meta:release:Code-Review+2: Elod Illes <elod.illes@est.tech>
meta:release:Workflow+1: Elod Illes <elod.illes@est.tech>

The global module documentation is no longer being generated
and the link points to a non-existent document.

The purpose of global module documentation is now fulfilled by
the automatically generated class, and function level reference
documents which are linked properly.

As such there is no need to keep the link around, or to
reestablish module level documentation.

Signed-off-by: Jiri Podivin <jpodivin@redhat.com>
Change-Id: I05e5144a36f33aa5feb996964d1a098b1716cf6a

cliff 3.9.0 release

meta:version: 3.9.0
meta:diff-start: -
meta:series: xena
meta:release-type: release
meta:pypi: yes
meta:first: no
meta:release:Author: Hervé Beraud <hberaud@redhat.com>
meta:release:Commit: Hervé Beraud <hberaud@redhat.com>
meta:release:Change-Id: I044ea7a8cd9de0e6b467a8c1c751555cb4961569
meta:release:Code-Review+2: Hervé Beraud <herveberaud.pro@gmail.com>
meta:release:Workflow+1: Hervé Beraud <herveberaud.pro@gmail.com>

cliff 3.8.0 release

meta:version: 3.8.0
meta:diff-start: -
meta:series: xena
meta:release-type: release
meta:pypi: yes
meta:first: yes
meta:release:Author: Hervé Beraud <hberaud@redhat.com>
meta:release:Commit: Hervé Beraud <hberaud@redhat.com>
meta:release:Change-Id: I8d3c3c932dc5c91f5e0476e14030124307991ae2
meta:release:Code-Review+1: Artem Goncharov <artem.goncharov@gmail.com>
meta:release:Code-Review+2: Thierry Carrez <thierry@openstack.org>
meta:release:Code-Review+2: Hervé Beraud <herveberaud.pro@gmail.com>
meta:release:Workflow+1: Hervé Beraud <herveberaud.pro@gmail.com>

The previous commit already ensures that the interactive help for
individual commands is sent to a pager. This does the same for the
'help' command with no arguments.

Change-Id: If5e38421d21e09f88a572dbb508b1997381bdb87

Using the autopage library we can automatically send the help output to
a pager (less, by default), git-style. The pager is configured to not
reset the terminal on exit, avoiding the problem when piping to less
manually that the help text you want to refer to disappears off the
screen when you go to use it. The pager is only invoked when the output
is to the terminal.

Since we invoke the pager, we can ensure that it is correctly set up to
interpret ANSI escape codes, so it is safe to use colour to make the
output easier to read. The autopage library provides light styling of
the default argparse help output, and some additional colour
highlighting is added here for the command list (which is generated by
cliff, not using argparse's formatting code).

Change-Id: If9e1aa5166da32c58cc0fa617f4f81eaa9b2c470
Depends-On: https://review.opendev.org/c/openstack/requirements/+/799343

Fedora is already testing Python 3.10 [1] and an issue
has been raised [2].
All the details are in the BZ ticket but TLDR is that
"optional arguments" was replaced with "options [3].
So, I used assertRegexp to accept both of them (i.e
"optional arguments" and "options").

[1] https://fedoraproject.org/wiki/Changes/Python3.10
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1914138
[3] https://github.com/python/cpython/commit/fb35fa49d192368e94ffec09c092260ed0fea2e1

Change-Id: I18d9f1bea7bb5a7afb273550314c36da7b466a69

If we are piping output to a command that exits before the entire
output is written (e.g. "head") then we will receive a BrokenPipeError.
This is expected and we should react by exiting gracefully, setting an
appropriate return code (128 + SIGPIPE).

Change-Id: I0d60e44450da1f48dbd8f459549da80fda69aad5

Adding conflict_handler as attribut in the Command class in order to be
able to take control of this parameter and change to different behavior
that argparse is handling: error / resolve / ignore.

Callers will be able to override it and get a proper Parser object.

Change-Id: I327ece99a04bc8b2ebfa554dea643b1f2a456336

Setuptools v54.1.0 introduces a warning that the use of
dash-separated options in 'setup.cfg' will not be supported
in a future version [1].
Get ahead of the issue by replacing the dashes with underscores.
Without this, we see 'UserWarning' messages
like the following on new enough
versions of setuptools:

  UserWarning: Usage of dash-separated 'description-file' will not be
  supported in future versions. Please use the underscore name
  'description_file' instead

[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb

Change-Id: Icccc9cc2b3a0d236746c4b58a8815d25d8b0a443

inspect.getargspec() is deprecated since py3

[1] https://docs.python.org/3/library/inspect.html#inspect.getargspec

Change-Id: I7a1692d9979e9ffaf781de1f39f5bfa59a01cf3c

Moving on py3 as the default runtime for tox to avoid to update this at
each new cycle.

Wallaby support officially the following runtimes [1]:
- Python 3.6
- Python 3.8

During Victoria Python 3.7 was used as the default runtime [2] however this
version isn't longer officially supported.

[1] https://governance.openstack.org/tc/reference/runtimes/wallaby.html#python-runtimes-for-wallaby
[2] https://governance.openstack.org/tc/reference/runtimes/victoria.html#python-runtimes-for-victoria

Change-Id: I5d419e881a42e627fd0699cb2ab68b66e7295cee

This is an automatically generated patch to ensure unit testing
is in place for all the of the tested runtimes for xena.

See also the PTI in governance [1].

[1]: https://governance.openstack.org/tc/reference/project-testing-interface.html

Change-Id: Id810ebcb6620b4f6235ef3d616b858b4ab6b18b4

cliff 3.7.0 release

meta:version: 3.7.0
meta:diff-start: -
meta:series: wallaby
meta:release-type: release
meta:pypi: yes
meta:first: no
meta:release:Author: Stephen Finucane <sfinucan@redhat.com>
meta:release:Commit: Stephen Finucane <sfinucan@redhat.com>
meta:release:Change-Id: I05a1700df84cf70fee868b3e7314940a8d54a1bd
meta:release:Code-Review+1: Artem Goncharov <artem.goncharov@gmail.com>
meta:release:Code-Review+1: Daniel Bengtsson <dbengt@redhat.com>
meta:release:Code-Review+2: Hervé Beraud <hberaud@redhat.com>
meta:release:Code-Review+2: Thierry Carrez <thierry@openstack.org>
meta:release:Workflow+1: Thierry Carrez <thierry@openstack.org>

PrettyTable was capped at a < 0.8, which meant we were getting the
veritably ancient 0.7.2 release first release in April 2013 (!) [1].
The project is now being maintained as a Jazzband project [2], meaning
we should switch to this new version.

The only significant change required here is that we no longer set the
'min_width' attribute since that actually does something - the wrong
thing - now. We want this attribute to set a lower bound on the wrap
width as opposed to an absolute minimum we can use, which is what
setting the 'min_width' attribute would do.

While we're here, we also remove a now useless bit of Python 2 code and
bump cmd2 to a slightly newer version.

[1] https://pypi.org/project/prettytable/#history
[2] https://github.com/jazzband/prettytable



Change-Id: Iceac729e7a9429e8ab25c60524a48d0aaeebeb37
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Depends-On: https://review.opendev.org/c/openstack/requirements/+/774917

Allow users to reverse sorting direction.

Change-Id: Iecd539139c5a7ce4abaaee2ff5632a2459437d51
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

Implement the '__lt__' magic method, thus providing the minimal set of
rich comparison methods necessary to support sorting. This will allows
users using these formatters for the more basic types (i.e. not dicts)
to sort their output using the standard '--sort-column' option.

Change-Id: I08e1f1bc75fa6452f19dfb9d221c1daec194d58d
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

One unfortunate change (or fortunate, depending on how you look at
types) in Python 3 is the inability to sort iterables of different
types. For example:

  >>> x = ['foo', 'bar', None, 'qux']
  >>> sorted(x)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: '<' not supported between instances of 'NoneType' and 'str'

Fortunately, we can take advantage of the fact that by providing a
function for the 'key' that returns a tuple, we can sort on multiple
conditions. In this case, "when the first key returns that two elements
are equal, the second key is used to compare." [1] We can use this to
first separate the values by whether they are None or not, punting those
that are not to the end, before sorting the non-None values normally.
For example:

  >>> x = ['foo', 'bar', None, 'qux']
  >>> sorted(x, key=lambda k: (k is None, k))
  ['bar', 'foo', 'qux', None]

We were already using this feature implicitly through our use of
'operator.itemgetter(*indexes)', which will return a tuple if there is
more than one item in 'indexes', and now we simply make that explicit,
fixing the case where we're attempting to compare a comparable type
with None. For all other cases, such as comparing a value that isn't
comparable, we surround things with a try-catch and a debug logging
statement to allow things to continue.

Note that we could optimize what we're done further by building a key
value that covers all indexes, rather than using a for loop to do so.
For example:

  >>> x = [('baz', 2), (None, 0), ('bar', 3), ('baz', 4), ('qux', 0)]
  >>> sorted(x, key=lambda k: list(
  ...     itertools.chain((k[i] is None, k[i]) for i in (0, 1)))
  ... )
  [('bar', 3), ('baz', 2), ('baz', 4), ('qux', 0), (None, 0)]

However, this would be harder to grok and would also mean we're unable
to handle exceptions on a single column where e.g. there are mixed types
or types that are not comparable while still sorting on the other
columns. Perhaps this would be desirable for some users, but sorting on
a best-effort basis does seem wiser and generally more user friendly.
Anyone that wants to sort on such columns should ensure their types are
comparable or implement their own sorting implementation.

[1] https://www.kite.com/python/answers/how-to-sort-by-two-keys-in-python



Change-Id: I4803051a6dd05c143a15923254af97e32cd39693
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Story: 2008456
Task: 41466

Change-Id: I040fccd1714dccd7a87aaf10d397ad3a3ef476d3

Change-Id: I27a3689c2e22452c082764eed8d26cd8f3bbcd13
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>