Change Ic7b71f1093671533c9f17fd621e02299bfbd7a6d reversed the order of
this list but didn't update the comment. Do so now.
Change-Id: I36f2dd791297a9e3df4f1e427db5b45017820bbf
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The previous ordering was confusing and placed new values before old
ones. Switch this order, making it more obvious what we're going *from*
and what we're going *to*. With this reordering, the old name no longer
makes sense so we rename the attribute.
Change-Id: Ic7b71f1093671533c9f17fd621e02299bfbd7a6d
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Correct a small logic error that would result in us passing an empty
'long_description' value to 'setup' if 'description_file' pointed to a
file that was empty. Fixing this also makes it a little more obvious
that we are only setting values that are present in 'setup.cfg', since
that wasn't totally clear before.
A small, unrelated typo is addressed.
Change-Id: Ib32b5fb5da84215376c8e372470b2ff08eb47908
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Attempt two at the problem, this time done properly. As discussed in
change I7158e75934535b80eb60d6b4b7dcef08866b5bab, the previous attempt
actually mapped 'python_requires' to 'requires_python' rather than the
other way around. This resolves that.
Change-Id: I415b64d5b51a248d2f45a28234f1635e8b82ffcc
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Dicts can't have duplicate keys. Lists of tuples can. We're going to
need duplicates.
Change-Id: Id43ba91585160448ad9737ba958ace5163d26f3d
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This reverts commit d5da2121f8. This was
done incorrectly. The 'D1_D2_SETUP_ARGS' dictionary modified here is a
mapping of distutils (and by extension, setuptools) supported options to
their legacy distutils2 equivalents, and is used to transform the latter
to the former. For example, consider the following entry:
"long_description": ("metadata", "description"),
This will transform an entry like so in a 'setup.cfg' file:
[metadata]
description = ...
Into the following equivalent call to setuptools' 'setup' function:
setup(
...,
long_description='...',
...
)
By that measure, the entry added in this change, namely:
"requires_python": ("metadata", "python_requires"),
Will result in a 'requires_python' argument being added to the 'setup'
call. That's not what we want. Rather, we likely want to transform a
'[metadata] requires_python' entry to a 'python_requires' argument to
'setup'.
The change is reverted here in expectation of a forthcoming proper fix.
Change-Id: I7158e75934535b80eb60d6b4b7dcef08866b5bab
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Odds are this was never used by any PBR-based projects, but was
included from the beginning to support a feature of Setuptools for a
utility which has been long since discouraged. As of Setuptools
46.2.0 and Python 3.9 it's generating deprecation warnings, and is
slated for removal from the Python 3.10 standard library.
https://bugs.python.org/issue40360https://github.com/pypa/setuptools/issues/2086
Change-Id: I6972984f29413d2534d802b142fa9323a7e4a4a3
Apparently requires-python is the old value and isn't valid
anymore. What people mean is python-requires. Of course, people
are still using the old value. Fix it for them.
Change-Id: Id49cf641f2eddac17f1b21b186aa3a150bd863f9
This allows us to run tox -epep8 on newer python versions. Fix the
issues newer hacking calls out. They were complaints about indentation
and ambigious l value variable names.
Change-Id: I9552fba791bdf54649fbe25fc26bffdf8186ff0a
A recent commit [1] broke Windows support by using shlex to
unquote paths.
The issue with shlex.split is that it doesn't work with Windows
paths, treating backslashes as escape characters.
We'll just replace backslashes with slashes before using shlex.split,
converting them back afterwards.
Closes-Bug: #1831242
[1] Id2cc32e4e40c1f834b19756e922118d8526358d3
Change-Id: Icb3abca004a35ab9760db8116fedfa96d012d0d0
Currently pbr fails if the description file contains unicode
characters. To fix this we need to open the description file as
utf-8 explicitly. Since open() in Python 2 doesn't support an
encoding parameter, use io.open() which works on both 2 and 3.
Co-Authored-By: Hervé Beraud<hberaud@redhat.com>
Change-Id: I1bee502ac84b474cc9db5523d2437a8c0a861c00
Closes-Bug: 1704472
Previously, when using data_files with a glob that matched a file with
whitespace in the name, pip would error with a message that the file
does not exist, e.g:
error: can't copy 'ansible/roles/yatesr.timezone/templates/timezone-Arch': doesn't exist or not a regular file
The problem was that ansible/roles/yatesr.timezone/templates/timezone-Arch
was a truncated form of the actual filename:
ansible/roles/yatesr.timezone/templates/timezone-Arch Linux.j2
Note the space in the filename and that it has been split on this space.
This change allows you to use a glob that matches files with whitespace
in the name. It does this by quoting the path.
Change-Id: Id2cc32e4e40c1f834b19756e922118d8526358d3
Fixes-Bug: 1810934
This was added to setuptools in [1] so we should support passing it
through from pbr.
Change-Id: I46493c18756bcb01c53575ab51ec5e5e97670fc3
1: b2ea3c4a20
Closes-Bug: 1760938
When keywords are defined as a list in cfg file the generated
output have errors and breaks metadata generation.
Change-Id: Ie8a5f30d6af1e81ecf3ca40bc94bc460cca38179
Closes-Bug: #1811475
Adding the comment flake8:noqa in a file will skip linting the entire
file. Most of the time, the intent was just to skip individual lines to
handle exception cases.
This gets rid of the "flake8:" prefix where it was used incorrectly and
fixes a few legitimate errors that were being hidden by the entire file
being skipped.
The behavior is change in flake8 to handle this better, which will
result in pep8 job failures if these are not fixes first. See more
information in the 3.6.0 release notes:
http://flake8.pycqa.org/en/latest/release-notes/3.6.0.html#features
Change-Id: I1af4eb8bef9d0d0e3aa3bbbfd66a2fcb8ab336cb
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Previous hyperlink was redirected to root of the new documentation
location which did not contain the right information.
New link points directly to the right location.
Change-Id: I3c83553a50036eadec74e7a00f3b312a7e5afa11
Expose the python_require setuptools option via the python-requires
metadata item in setup.cfg.
Closes-Bug: 1735668
Change-Id: Idf2bb90882121e118f5b7531e027d350c0e4a441
Co-authored-by: Dennis Verspuij <dennisverspuij@users.noreply.github.com>
Per the referenced bug, relying on the terminal encoding to read
setup.cfg is not safe. Unfortunately, Python 2 doesn't accept an
encoding when reading config files so we need a fallback path for
that version.
Change-Id: If49344db2f9139c0557f6acd17671163e02468a5
Closes-Bug: 1745396
We were treating this a single line, comma- or space-delimited option.
This was incorrect and was causing issues for projects like neutron-lib
when Sphinx 1.7, which switches from optparse to the stricter argparse
was used. In addition, this project was including comments in the
multi-line opt. These were being passed through but Sphinx < 1.7 was
simply ignoring them. These are now filtered out.
Change-Id: I177edf0f44714175da220cf3a960b8f23aa4ab09
Closes-Bug: #1753082
In bindep files we use a 'test' environment to indicate dependencies
that are needed for testing. Make the same thing available for our
python dependencies, allowing things like "pip install .[test]" or "pip
install shade[test]" to work.
Change-Id: If3ad8b6a79a8cab2f7434b73207f35384e8516ba
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
The 'monkeypatch_method' function no longer has any callers and can be
removed.
Change-Id: I402eb482d2c1db7331bd872c5169db8e59c9a34f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The revert in Ia6cfbfe5b10a5b714fbb9f21ca61380aaf231638 actually
broke Sphinx 1.3.x support again. Try to fix it for real this
time by avoiding an exception on missing man_pages.
NOTE(dmllr): don't change dict while iterating over it, hopefully
this fixes the gating failure with python 3.5.x
Change-Id: I52d45fa0a0d42de690d3a492068f7bb03483a224
Related-Bug: 1379998
This patch set modifies lines which are importing objects
instead of modules. As per openstack import guide lines, user should
import modules in a file not objects.
http://docs.openstack.org/developer/hacking/#imports
Change-Id: Iab667c04f4aa57d0c8c882144a550443dacc8f05
As per OpenStack Docstrings guide lines [1]:
[H401] Docstrings should not start with a space.
[H403] Multi line docstrings should end on a new line.
[H404] Multi line docstrings should start without a leading new line.
[H405] Multi line docstrings should start with a one line summary
followed by an empty line.
[1] http://docs.openstack.org/developer/hacking/#docstrings
Change-Id: Ic943e837b8b4f55c2957643ad29dfa004b3c2eb3
tox -e py34 is reporting a deprecation warning for SafeConfigParser
/octavia/.tox/py34/lib/python3.4/site-packages/pbr/util.py:207:
DeprecationWarning: The SafeConfigParser class has been renamed to
ConfigParser in Python 3.2. This alias will be removed in future
versions. Use ConfigParser directly instead.
parser = configparser.SafeConfigParser()
Closes-Bug: #1618666
Change-Id: Ib280b778938b64717ee1cf94efae2f7b553c8f5e
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
We are silently dropping requirements that do not parse, do not do this
and bubble the error up.
Change-Id: I5bfce7c7d0be2ccd880e78509856074a09c57166
Closes-Bug: 1554331
In patch 789888 we began relying on EntryPoint.resolve(), which only
exists in setuptools >= 12, breaking support for setuptools < 12. This
includes the default virtualenv installations from may LTS distributions.
As ep.load with arguments is deprecated we will attempt to use
ep.resolve if it exists and fall back to ep.load(false) if it does not.
setuptools 11 is the odd release out, as this was when load with
arguments was deprecated, suggesting the use of ep._load. We will
continue to use ep.load(False) here.
Change-Id: I272f76fef7e447378697a3980372191f4ffe1a2f
Old versions of pip do not properly evaluate blank envmarkers such as
':python_version>=2.7', so as long as we are not creating a bdist_wheel
we evaluate these immediately to support these old installations
Change-Id: I94a5f9bccd658a2529a727d99f5a2b79e6b00aa8
Closes-Bug: 1502692
Distribution().get_command_list() is not hooked by setuptools like
print_commands() is, as such we do not get a complete command list.
Here we perform the hook ourselves to prevent the need to depend on
a super new version of setuptools.
Change-Id: Ie6088aedb92713be4b8b9af4a4ce3d300a114d7b
When processing setup.cfg strip trailing comments from lines as this is
unsupported by setuptools.
Change-Id: I7712c07552b50830549644a6ff4167b90d897125
Closes-bug: 1494330
If there are boolean conditions in the env marker, the existing join
causes the extra tag to only be applied to the first of them, causing
carnage.
Change-Id: I7b735befae76b330f923276e1c48ef23816774d4
This adds support for reading extras from setup.cfg.
It also adds support for handling environment markers, both in the
extras section and in install_requires and in requirements.txt.
Change-Id: I6fd8276012e65f82934df9c374613b1ce6856b5a
Stop including git sha in version strings
We include it in pbr.json now. Including it is contentious in the world
of python, and it's up for debate as to whether or not it provides value.
Write and read more complex git sha info
Instead of encoding the git sha into the version string, add it to
a metadata file. This will allow us to get out of the business of
arguing with pip and setuptools about version info. In order to make
this really nice, provide a command line utility called "pbr" that has
subcommands to print out the metadata that we're now including in the
egg-info dir.
Only import sphinx during hook processing
When pbr is imported to handle writing the egg_info file because of
the entry point, it's causing sphinx to get imported. This has a
cascading effect once docutils is trying to be installed on a system
with pbr installed. If some of the imports fail along the way, allow
pbr to continue usefully but without the Sphinx extensions
available. Eventually, when everything is installed, those
extensions will work again when the commands for build_sphinx, etc.
are run separately.
Also slip in a change to reorder the default list of environments
run by tox so the testr database is created using a dbm format
available to all python versions.
Integration test PBR commits
Make sure that if a PBR commit is being tested then we install and
use that source rather than the latest PBR release.
Change-Id: Ie121e795be2eef30822daaa5fe8ab1c2315577ae
(cherry picked from commit 65f4fafd90)
(cherry picked from commit cd7da23937)
Closes-Bug: #1403510
Co-Authored-By: Clark Boylan <clark.boylan@gmail.com>
Co-Authored-By: Doug Hellmann <doug@doughellmann.com>
Co-Authored-By: Jeremy Stanley <fungi@yuggoth.org>
Forcing the log level to info causes pbr to emit status log messages
in a way that breaks commands like "python setup.py --maintainer" and
"python setup.py --name", which are useful when scripting operations
that work on packages.
Change-Id: I6607c96e171f2f8efa89bd701018f4af6ec9c15a
Implement a local egg_info command that only re-generates the
SOURCES.txt file when we need to. That is:
- If there is no SOURCES.txt, make one
- If we have run the sdist command, make one
Otherwise, leave well enough alone.
Also, skip doing any git processing if SKIP_GIT_SDIST is specified.
This should mean that consumers of our tarballs should not get screwed
by the need to inject git processing into the sdist.
Change-Id: I163b1c153d030e79b120600a2890edeb49e1fa90
Stephen Finucane