In change I1f2b4d34e587389f7e11b99d000e14477cf5091b, we attempted to
resolve an issue whereby using PBR as a PEP-517 backend could result in
recursion. We did this by setting 'dist.pbr' to 'None' but later
discovered this introduced a regression that prevented us from writing
the 'pbr.json' file into generated sdists. The fix for the regression,
change I407ae88ab8de4b61f94034b3d79a2ca7f7d79d16, stopped setting
'dist.pbr' to 'None' and instead set a global flag to indicate whether
we had already been called or not. Unfortunately it seems this fix is
also insufficent. As discussed in tox#2712 [1], tox v4 has implemented
its own implementation of PEP-517 - 'pyproject-api' [2] - and unlike
'build' this implementation optionally allows re-use of the backend
process for multiple PEP-517 commands. tox's 'Pep517VirtualEnvFrontend'
does just this. This means if we run multiple commands that require
generation of a 'Distribution' object - say,
'prepare_metadata_for_build_wheel' followed by 'build_sdist' - anything
but the first step will not result in proper population of said
'Distribution' objects.
The solution to this issue is simple: per $subject, instead of setting
our recursion-detection canary at the module level, set it at the
Distribution level.
[1] https://github.com/tox-dev/tox/issues/2712
[2] github.com/tox-dev/pyproject-api/
Change-Id: I67909d732a74550fbcd7c06a9e2f4ac88c063444
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Add a check in pbr.core.pbr() to make sure it hasn't already run,
and return immediately if it has. This replaces the earlier attempt
at loop-busting by setting the entrypoint to None in the dist, in
order to support PEP 517 builds without setup_requires.
Also test that pbr.json is now included in the dist tree, in order
to avoid future regressions.
Change-Id: I407ae88ab8de4b61f94034b3d79a2ca7f7d79d16
When using PBR PEP517 support without setup_requires were were
infinitely recursing because Distribution.finalize_options calls pbr()
and pbr() calls Distribution.finalize_options. With a setup_requires
this doesn't seem to happen because something is resetting dist.pbr's
value from True (callable) to None (not callable) after the initial
pbr() call and before further recursion can occur.
Explicitly enforce this behavior in pbr() via an explicit update of
dist.pbr to None to avoid calling pbr() more than once resulting in the
unwanted loop.
Change-Id: I1f2b4d34e587389f7e11b99d000e14477cf5091b
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>
As described in the pypa pull request, special-case passing through
these fields into the metadata. setuptools will maintain them.
Change-Id: I89eb8c6d627790680a61a0a4b7490191b6e8e90c
Closes-Bug: #1762494
This was done in change I7418cc3ab36823d029a93f86df9c8b25aa7b0c5f to
keep the diff clean [1]. If can be removed now.
[1] https://bugs.launchpad.net/pbr/+bug/1620153/comments/1
Change-Id: Id66ca0522cc4c5601714e1e9ba9379492edc5905
Discovering the underlying Distribution class through the class
hierarchy saves unpatching and repatching.
Based on commits ed579a5dbb2a1843874969a58bb2b6f1eca2e50d and
10b87cc1eb92f50906ff645d0221c74f03de94b9 from [1].
[1] https://github.com/jaraco/pbr/commits/issue-1620153-signoff
Closes-Bug: #1620153.
Change-Id: I7418cc3ab36823d029a93f86df9c8b25aa7b0c5f
Signed-off-by: Jason R. Coombs <jaraco@jaraco.com>
Signed-off-by: Monty Taylor <mordred@inaugust.com>
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
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
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
Enabled H405 multi line docstring summary not separated with an empty
line in tox testing.
Change-Id: I1a4bfbd2bad6eb2c132843ca21451807737121df
Closes-Bug:#1524176
pbr is monkeypatching the Distribution intstance in setuptools, which is
OK I guess, but then it never puts it back how it left it. As a
consequence, whenever pbr installs before another project in a setup.py,
it breaks setuptools for everything that comes after it. This patch
will restore the Distribution instance.
Closes-Bug: 1324784
Change-Id: I20fbf255c634685e82f7b11987d2725de8280b9d
Set the integer_types variable to the same kind of object
under python 3 and 2 so that when we go to manipulate it
later it works.
Change-Id: I8f9db1d76931ef834645095952f71415d98f0b5c
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
Stephen Finucane