Setuptools deprecated -'s at some point and they result in a bunch of
warnings in failed tests. This is distracting and eventually is likely
to create real errors. Go ahead and fix them now.
Change-Id: If3594269495ae1f3cefffd4c4f38d87af5c7fdfe
The git web URL is now: https://opendev.org/openstack/pbr
Also stop linking README.rst to no more existing history/changelog
documentation page (removed by 96b84a9014).
Change-Id: I56b0e2b86a7fc66c5ae25e06175033a885f500f6
The metadata field, 'python-requires' was introduced in PEP440 and
appears to have superseded 'requires-python'. [1] The metadata that pbr
uses for itself and it's test package was using the old incorrect field,
this commit updates it to be the proper metadata to show a working
example. To a certain extent it probably doesn't matter because it's very
unlikely someone will try to install pbr with python 2.5, but it's more
about making sure that pbr itself is leading by example and that it's own
config actually works.
[1] https://github.com/mtreinish/stestr/issues/292
Change-Id: I5eb14d490a3731b6b95d7a1137c33ec2d73f193f
As of setuptools 36.4.0, support for Description-Content-Type
metadata was added via the long_description_content_type variable.
Add a metadata.description-content-type option for setup.cfg so it
can be provided through PBR. This makes it possible to instruct PyPI
and potentially other frontends to know an explicit RFC 1341 content
type, along with character set and variant, for the accompanying
long description.
Change-Id: I852f603d9ca4e4cd469eab4cae9933ef2581e3af
By including one or more Project-URL entries in PKG-INFO metadata,
PyPI can display helpful hyperlinks in a generic manner. Add support
here to be able to pass it through setup.cfg with a project_urls
dict. See the corresponding section of the Core Metadata
Specifications from the Python Packaging User Guide for details:
https://packaging.python.org/specifications/core-metadata/#project-url-multiple-use
Setuptools implementation is underway here:
https://github.com/pypa/setuptools/pull/1210
Change-Id: I14e580c654b619cab7eb24e31f736056d6cf9bd4
distutils2 is long dead and many of its best ideas have been
incorporated into setuptools. One of the ideas that *has not* been
incorporated is the idea of command hooks, of either the pre or post
kind. pbr is still carrying the code for this, and there are several
issues with this:
- No one is using this functionality in OpenStack and, given the
complete lack of documentation on the matter, it's very doubtful that
it's being used anywhere else [1]
- It's causing issues for projects attempting to hook into the
'distutils.commands' entry point on Python 2.7, which it seems no else
must have attempted yet [2].
- distutils2 is dead and advanced features like this that we don't
explicitly need should not be retained
We could attempt to fix this but why bother? Good riddance, I say.
[1] http://codesearch.openstack.org/?q=pre_hook%5C.&i=nope&files=&repos=
[2] http://codesearch.openstack.org/?q=distutils.commands&i=nope&files=&repos=
Change-Id: I01f657034cffbf55ce830b7e8dbb6b3d94c1fd18
This legacy option provided the ability to fail on doc warnings.
However, this functionality is broken in recent releases and now exists
in Sphinx itself (since 1.5.0). Rather that fixing it and causing a
whole load of doc build errors introduced in the time since this option
was broken, remove it, preferring the new Sphinx option instead.
This allows us to remove a lot of test code which is essentially testing
Sphinx functionality only now, based on the assumption that Sphinx do
adequate testing themselves.
Change-Id: Ia4b6adefcd437cb1ceb4558b004c17359df2486d
We're currently ignoring data-files, and it looks like the problem
would sometimes be present starting with 2796f9, 0.5.7, and always be present
from 04984a, 0.5.15.
This normalises all config keys from - to _ as soon as we read the
config, which means future access and modification does not need to
concern itself with the possibility of the key being a '-' instead '_'.
This should make it more difficult for code accessing/modifying values
in the config to clobber user set values or be unaware of them, like
in the case of the files hook.
As well, support download-url, but properly expose it as download_url.
Co-Authored-By: Julien Danjou <julien@danjou.info>
Change-Id: I062774c706b8f7339dda46689a226b80ae6ac277
As we attempt to get more of OpenStack API servers to be runnable as a
regular WSGI application, we should provide support in PBR for
building these base scripts just like the console scripts.
This adds a new 'wsgi_scripts' group which builds a base script that
will run under mod_wsgi as expected. It also has a CLI fallback mode,
so that the application can be brought up as a wsgiref simple_server
for quick local testing and development. All wsgiref servers default
to binding to port 8000, but that can be overridden.
To support this, and possible future expansion of the script types,
the group list now iterates over a dictionary of group_name =>
template mappings.
This includes basic testing.
It also includes tests which would run an actual wsgi
environment. These are currently skipped as they can't be reliably run
in the gate for timing reasons on stdout processing.
Change-Id: I334639d7ecaad2703d1ff675880a314cc28e2334
Due to an oversight in testing (the tests for local dev versions were
all running with PBR_VERSION in the environment) we did not handle
enough variety of local development versions.
Specific new cases we now handle:
- untagged trees - where git describe returns just the sha
- tags with versions with less than two components (e.g. 1)
Change-Id: Ieaeca592b6ba26c5da50dcad3fb6e7551431d50e
Co-Authored-By: Robert Collins <rbtcollins@hp.com>
* Previously console_scripts could only reference functions:
script_name = package.name:function_name
This change adds support for classmethods:
script_name = package.name:ClassName.classmethod_name
This change is necessary to support a Neutron use-case.
* Fixes bug 1206734
Change-Id: I9509d3f2cea29fee5696936dbbb1d507764f1e81
The console scripts generated by entry_points are too complex for
our needs and make things run slowly in service of a multi-version
install that we don't use.
Instead, install a simple script which just does a direct import.
Change-Id: I1ec46837cea07db514f2fb6338c7bced34a83c4a
When we merged in d2to1, we kept it separate, but I don't think there
is a great benefit to doing that.
Change-Id: I3972b3132619e8e2dd7e362ca5fe9d1e3add43b8
Clark Boylan