See https://src.fedoraproject.org/rpms/python-setuptools/pull-request/40
Strictly speaking, this is not an RPM generator, but:
- it generates provides
- it is tighly coupled with pythondistdeps.py
Usage:
1. Run `$ /usr/lib/rpm/pythonbundles.py .../vendored.txt`
2. Copy the output into the spec as a macro definition:
%global bundled %{expand:
Provides: bundled(python3dist(appdirs)) = 1.4.3
Provides: bundled(python3dist(packaging)) = 16.8
Provides: bundled(python3dist(pyparsing)) = 2.2.1
Provides: bundled(python3dist(six)) = 1.15
}
3. Use the macro to expand the provides
4. Verify the macro contents in %check:
%check
...
%{_rpmconfigdir}/pythonbundles.py src/_vendor/vendored.txt --compare-with '%{bundled}'
The %__python_magic filter suddenly got actually working with file 5.39:
Before:
file.cpython-38.opt-1.pyc: data
After:
file.cpython-38.opt-1.pyc: python 3.8 byte-compiled
Hence, the filter started to pick all Python files regardless of their location.
Later, in the actual generator, paths like this were considered:
/opt/usr/lib/python3.X/...
And generated requirements on python(abi).
We don't actually need to filter the files by file magic,
so we drop it to get the previously accidentally working behavior.
We could choose if the path and magic filters are applied as OR or AND.
However, we don't want either.
We actually want to mach any files in Python directories regardless of their magic.
We *could* filter by file type (and executable bit) for provides,
but that would require us to split the attr files into two.
That is, we add new provides that replace dots with a dash.
Package that used to provide python3dist(zope.component) and python3.8dist(zope.component)
now also provides python3dist(zope-component) and python3.8dist(zope-component).
Package that used to provide python3dist(a.-.-.-.a) now provides python3dist(a-a) as well.
This is consistent with pip behavior, `pip install zope-component` installs zope.component.
Historically, we have always used dist.key (safe_name) from setuptools,
but that is a non-standardized convention -- whether or not it replaces dots
with dashes is not even documented.
We say we use "canonical name" or "normalized name" everywhere, yet we didn't.
We really need to follow the standard (PEP 503):
https://www.python.org/dev/peps/pep-0503/#normalized-names
The proper function here would be packaging.utils.canonicalize_name
https://packaging.pypa.io/en/latest/utils/#packaging.utils.canonicalize_name
-- we reimplement it here to avoid an external dependency.
This is the first required step needed if we want to change our requirements later.
If we decide we don't, for whatever reason, this doesn't break anything.
Puts bounded requirements into parenthesis
Fixes: https://github.com/rpm-software-management/rpm/issues/995
Upstream: https://github.com/rpm-software-management/rpm/pull/996
For this input: pyparsing>=2.0.1,!=2.0.4,!=2.1.2,!=2.1.6
Instead of (invalid):
(python3.8dist(pyparsing) >= 2.0.1 with
python3.8dist(pyparsing) < 2.1.2 or python3.8dist(pyparsing) >= 2.1.2.0 with
python3.8dist(pyparsing) < 2.1.6 or python3.8dist(pyparsing) >= 2.1.6.0 with
python3.8dist(pyparsing) < 2.0.4 or python3.8dist(pyparsing) >= 2.0.4.0)
Produces (valid):
(python3.8dist(pyparsing) >= 2.0.1 with
(python3.8dist(pyparsing) < 2.1.2 or python3.8dist(pyparsing) >= 2.1.2.0) with
(python3.8dist(pyparsing) < 2.0.4 or python3.8dist(pyparsing) >= 2.0.4.0) with
(python3.8dist(pyparsing) < 2.1.6 or python3.8dist(pyparsing) >= 2.1.6.0))
For this input: babel>=1.3,!=2.0
Instead of (invalid):
(python3.8dist(babel) >= 1.3 with
python3.8dist(babel) < 2 or python3.8dist(babel) >= 2.0)
Produces (valid):
(python3.8dist(babel) >= 1.3 with
(python3.8dist(babel) < 2 or python3.8dist(babel) >= 2.0))
For this input: pbr!=2.1.0,>=2.0.0
Instead of (invalid):
(python3.8dist(pbr) >= 2 with
python3.8dist(pbr) < 2.1 or python3.8dist(pbr) >= 2.1.0)
Produces (valid):
(python3.8dist(pbr) >= 2 with
(python3.8dist(pbr) < 2.1 or python3.8dist(pbr) >= 2.1.0))
The purelib and platlib were both defined to /usr/lib64/python on
64bits systems. This is because:
>>> get_python_lib(standard_lib=1, plat_specific=0)
'/usr/lib64/python3.7'
>>> get_python_lib(standard_lib=1, plat_specific=1)
'/usr/lib64/python3.7'
>>> get_python_lib(standard_lib=0, plat_specific=0)
'/usr/lib/python3.7/site-packages'
>>> get_python_lib(standard_lib=0, plat_specific=1)
'/usr/lib64/python3.7/site-packages'
So now we use standard_lib=0 to get the site-packages base path
from /usr/lib and not /usr/lib64.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1609492
Running this python script on all possible files is way too expensive.
Some of the packages timeout due to that.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
This package is not being kept up to date, it's hard to maintain and we
will need to tune it from time to time which is painful.
Also removes whole layer of bootstrapping.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
