2019-07-02 10:41:04 +00:00
|
|
|
Name: pyproject-rpm-macros
|
2019-07-02 14:53:05 +00:00
|
|
|
Summary: RPM macros for PEP 517 Python packages
|
2019-07-02 10:41:04 +00:00
|
|
|
License: MIT
|
2019-07-02 14:53:05 +00:00
|
|
|
|
2019-07-17 15:34:24 +00:00
|
|
|
%bcond_without tests
|
|
|
|
|
|
2019-07-02 14:53:05 +00:00
|
|
|
# Keep the version at zero and increment only release
|
|
|
|
|
Version: 0
|
Handle backends with colon, fallback to setuptools.build_meta:__legacy__
Falling back to setuptools.build_meta:__legacy__ is the standard behavior,
not setuptools.build_meta. See PEP 517:
https://www.python.org/dev/peps/pep-0517/
> If the pyproject.toml file is absent, or the build-backend key is missing,
> the source tree is not using this specification, and tools should revert
> to the legacy behaviour of running setup.py (either directly, or by
> implicitly invoking the setuptools.build_meta:__legacy__ backend).
Falling back to setuptools.build_meta had very similar results so far.,
but the behavior might change in the feature.
While working on this, I have uncovered a problem in our code.
It was not able to handle backends with ":". Looking at PEP 517 again:
> build-backend is a string naming a Python object that will be used to
> perform the build. This is formatted following the same module:object syntax
> as a setuptools entry point. For instance, if the string is "flit.api:main",
> this object would be looked up by executing the equivalent of:
>
> import flit.api
> backend = flit.api.main
>
> It's also legal to leave out the :object part, e.g.
>
> build-backend = "flit.api"
>
> which acts like:
>
> import flit.api
> backend = flit.api
We now handle such cases properly. Witch the change of the default backend,
we also test a backend with colon in our tests.
2020-02-05 12:10:51 +00:00
|
|
|
Release: 12%{?dist}
|
2019-07-02 14:53:05 +00:00
|
|
|
|
2019-07-02 10:41:04 +00:00
|
|
|
Source0: macros.pyproject
|
2019-07-02 14:53:05 +00:00
|
|
|
Source1: pyproject_buildrequires.py
|
|
|
|
|
|
|
|
|
|
Source8: README.md
|
|
|
|
|
Source9: LICENSE
|
|
|
|
|
|
2019-07-17 13:44:22 +00:00
|
|
|
Source10: test_pyproject_buildrequires.py
|
|
|
|
|
Source11: testcases.yaml
|
|
|
|
|
|
2019-07-02 11:05:10 +00:00
|
|
|
URL: https://src.fedoraproject.org/rpms/pyproject-rpm-macros
|
2019-07-02 14:53:05 +00:00
|
|
|
|
2019-07-02 10:41:04 +00:00
|
|
|
BuildArch: noarch
|
|
|
|
|
|
|
|
|
|
Requires: python3-pip >= 19
|
|
|
|
|
Requires: python3-devel
|
|
|
|
|
|
2019-08-10 12:34:24 +00:00
|
|
|
# We keep these here for now to avoid one loop of %%generate_buildrequires
|
|
|
|
|
# But those are also always in the output of %%generate_buildrequires
|
|
|
|
|
# in order to be removable in the future
|
|
|
|
|
Requires: python3dist(packaging)
|
|
|
|
|
Requires: python3dist(pytoml)
|
|
|
|
|
|
|
|
|
|
# This is not output from %%generate_buildrequires to work around:
|
|
|
|
|
# https://github.com/rpm-software-management/mock/issues/336
|
|
|
|
|
Requires: (python3dist(importlib-metadata) if python3 < 3.8)
|
|
|
|
|
|
2019-07-17 15:34:24 +00:00
|
|
|
%if %{with tests}
|
2019-07-17 13:44:22 +00:00
|
|
|
BuildRequires: python3dist(pytest)
|
|
|
|
|
BuildRequires: python3dist(pyyaml)
|
|
|
|
|
BuildRequires: python3dist(packaging)
|
2019-08-10 12:34:24 +00:00
|
|
|
%if 0%{fedora} < 32
|
|
|
|
|
# The %%if should not be needed, it works around:
|
|
|
|
|
# https://github.com/rpm-software-management/mock/issues/336
|
|
|
|
|
BuildRequires: (python3dist(importlib-metadata) if python3 < 3.8)
|
|
|
|
|
%endif
|
2019-07-17 13:44:22 +00:00
|
|
|
BuildRequires: python3dist(pytoml)
|
|
|
|
|
BuildRequires: python3dist(pip)
|
2019-07-17 16:16:16 +00:00
|
|
|
BuildRequires: python3dist(setuptools)
|
2019-08-13 12:42:21 +00:00
|
|
|
BuildRequires: python3dist(tox-current-env) >= 0.0.2
|
2019-07-17 16:16:16 +00:00
|
|
|
BuildRequires: python3dist(wheel)
|
2019-07-17 15:34:24 +00:00
|
|
|
%endif
|
2019-07-17 13:44:22 +00:00
|
|
|
|
|
|
|
|
|
2019-07-02 10:41:04 +00:00
|
|
|
%description
|
|
|
|
|
This is a provisional implementation of pyproject RPM macros for Fedora 30+.
|
|
|
|
|
These macros are useful for packaging Python projects that use the PEP 517
|
|
|
|
|
pyproject.toml file, which specifies the package's build dependencies
|
|
|
|
|
(including the build system, such as setuptools, flit or poetry).
|
|
|
|
|
|
2019-07-02 14:53:05 +00:00
|
|
|
|
2019-07-02 10:41:04 +00:00
|
|
|
%prep
|
2019-07-02 11:40:47 +00:00
|
|
|
# Not strictly necessary but allows working on file names instead
|
|
|
|
|
# of source numbers in install section
|
|
|
|
|
%setup -c -T
|
|
|
|
|
cp -p %{sources} .
|
2019-07-02 10:41:04 +00:00
|
|
|
|
|
|
|
|
%build
|
|
|
|
|
# nothing to do, sources are not buildable
|
|
|
|
|
|
|
|
|
|
%install
|
2019-07-02 14:53:05 +00:00
|
|
|
mkdir -p %{buildroot}%{_rpmmacrodir}
|
|
|
|
|
mkdir -p %{buildroot}%{_rpmconfigdir}/redhat
|
|
|
|
|
install -m 644 macros.pyproject %{buildroot}%{_rpmmacrodir}/
|
|
|
|
|
install -m 644 pyproject_buildrequires.py %{buildroot}%{_rpmconfigdir}/redhat/
|
2019-07-02 10:41:04 +00:00
|
|
|
|
2019-07-17 15:34:24 +00:00
|
|
|
%if %{with tests}
|
2019-07-17 13:44:22 +00:00
|
|
|
%check
|
|
|
|
|
%{__python3} -m pytest -vv
|
2019-07-17 15:34:24 +00:00
|
|
|
%endif
|
2019-07-17 13:44:22 +00:00
|
|
|
|
|
|
|
|
|
2019-07-02 10:41:04 +00:00
|
|
|
%files
|
|
|
|
|
%{_rpmmacrodir}/macros.pyproject
|
2019-07-02 14:53:05 +00:00
|
|
|
%{_rpmconfigdir}/redhat/pyproject_buildrequires.py
|
2019-07-02 10:41:04 +00:00
|
|
|
|
|
|
|
|
%doc README.md
|
|
|
|
|
%license LICENSE
|
|
|
|
|
|
|
|
|
|
%changelog
|
Handle backends with colon, fallback to setuptools.build_meta:__legacy__
Falling back to setuptools.build_meta:__legacy__ is the standard behavior,
not setuptools.build_meta. See PEP 517:
https://www.python.org/dev/peps/pep-0517/
> If the pyproject.toml file is absent, or the build-backend key is missing,
> the source tree is not using this specification, and tools should revert
> to the legacy behaviour of running setup.py (either directly, or by
> implicitly invoking the setuptools.build_meta:__legacy__ backend).
Falling back to setuptools.build_meta had very similar results so far.,
but the behavior might change in the feature.
While working on this, I have uncovered a problem in our code.
It was not able to handle backends with ":". Looking at PEP 517 again:
> build-backend is a string naming a Python object that will be used to
> perform the build. This is formatted following the same module:object syntax
> as a setuptools entry point. For instance, if the string is "flit.api:main",
> this object would be looked up by executing the equivalent of:
>
> import flit.api
> backend = flit.api.main
>
> It's also legal to leave out the :object part, e.g.
>
> build-backend = "flit.api"
>
> which acts like:
>
> import flit.api
> backend = flit.api
We now handle such cases properly. Witch the change of the default backend,
we also test a backend with colon in our tests.
2020-02-05 12:10:51 +00:00
|
|
|
* Wed Feb 05 2020 Miro Hrončok <mhroncok@redhat.com> - 0-12
|
|
|
|
|
- Fallback to setuptools.build_meta:__legacy__ backend instead of setuptools.build_meta
|
|
|
|
|
- Properly handle backends with colon
|
2020-02-05 13:33:50 +00:00
|
|
|
- Preserve existing flags in shebangs of Python files in /usr/bin
|
Handle backends with colon, fallback to setuptools.build_meta:__legacy__
Falling back to setuptools.build_meta:__legacy__ is the standard behavior,
not setuptools.build_meta. See PEP 517:
https://www.python.org/dev/peps/pep-0517/
> If the pyproject.toml file is absent, or the build-backend key is missing,
> the source tree is not using this specification, and tools should revert
> to the legacy behaviour of running setup.py (either directly, or by
> implicitly invoking the setuptools.build_meta:__legacy__ backend).
Falling back to setuptools.build_meta had very similar results so far.,
but the behavior might change in the feature.
While working on this, I have uncovered a problem in our code.
It was not able to handle backends with ":". Looking at PEP 517 again:
> build-backend is a string naming a Python object that will be used to
> perform the build. This is formatted following the same module:object syntax
> as a setuptools entry point. For instance, if the string is "flit.api:main",
> this object would be looked up by executing the equivalent of:
>
> import flit.api
> backend = flit.api.main
>
> It's also legal to leave out the :object part, e.g.
>
> build-backend = "flit.api"
>
> which acts like:
>
> import flit.api
> backend = flit.api
We now handle such cases properly. Witch the change of the default backend,
we also test a backend with colon in our tests.
2020-02-05 12:10:51 +00:00
|
|
|
|
2020-01-30 10:14:51 +00:00
|
|
|
* Thu Jan 30 2020 Fedora Release Engineering <releng@fedoraproject.org> - 0-11
|
|
|
|
|
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
|
|
|
|
|
|
2019-11-13 11:39:36 +00:00
|
|
|
* Fri Nov 15 2019 Patrik Kopkan <pkopkan@redhat.com> - 0-10
|
|
|
|
|
- Install wheel in '$PWD/pyproject-macros-wheeldir' to have more explicit path from which we install.
|
|
|
|
|
- The path can be changed by redefining %%_pyproject_wheeldir.
|
|
|
|
|
|
2019-11-13 11:41:31 +00:00
|
|
|
* Wed Nov 13 2019 Anna Khaitovich <akhaitov@redhat.com> - 0-9
|
|
|
|
|
- Remove stray __pycache__ directory from /usr/bin when running %%pyproject_install
|
|
|
|
|
|
When tox fails, print tox output before failing
Previously, it wasn't possible to see why tox failed:
...
Requirement satisfied: tox-current-env >= 0.0.2
(installed: tox-current-env 0.0.2)
Traceback (most recent call last):
File "/usr/lib/rpm/redhat/pyproject_buildrequires.py", line 269, in main
generate_requires(
File "/usr/lib/rpm/redhat/pyproject_buildrequires.py", line 221, in generate_requires
generate_tox_requirements(toxenv, requirements)
File "/usr/lib/rpm/redhat/pyproject_buildrequires.py", line 184, in generate_tox_requirements
r = subprocess.run(
File "/usr/lib64/python3.8/subprocess.py", line 512, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['tox', '--print-deps-to-file', '/tmp/tmp96smu4rv', '-qre', 'py38']' returned non-zero exit status 1.
Now it is:
...
Requirement satisfied: tox-current-env >= 0.0.2
(installed: tox-current-env 0.0.2)
ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found
Traceback (most recent call last):
File "/usr/lib/rpm/redhat/pyproject_buildrequires.py", line 270, in main
generate_requires(
File "/usr/lib/rpm/redhat/pyproject_buildrequires.py", line 222, in generate_requires
generate_tox_requirements(toxenv, requirements)
File "/usr/lib/rpm/redhat/pyproject_buildrequires.py", line 193, in generate_tox_requirements
r.check_returncode()
File "/usr/lib64/python3.8/subprocess.py", line 444, in check_returncode
raise CalledProcessError(self.returncode, self.args, self.stdout,
subprocess.CalledProcessError: Command '['tox', '--print-deps-to-file', '/tmp/tmpwp8sffv1', '-qre', 'py38']' returned non-zero exit status 1.
Inspired by https://src.fedoraproject.org/rpms/python-chaospy/pull-request/1#comment-32750
2019-10-25 14:51:01 +00:00
|
|
|
* Fri Oct 25 2019 Miro Hrončok <mhroncok@redhat.com> - 0-8
|
|
|
|
|
- When tox fails, print tox output before failing
|
|
|
|
|
|
2019-10-08 11:01:08 +00:00
|
|
|
* Tue Oct 08 2019 Miro Hrončok <mhroncok@redhat.com> - 0-7
|
|
|
|
|
- Move a verbose line of %%pyproject_buildrequires from stdout to stderr
|
|
|
|
|
|
2019-09-20 08:18:12 +00:00
|
|
|
* Fri Jul 26 2019 Petr Viktorin <pviktori@redhat.com> - 0-6
|
|
|
|
|
- Use importlib_metadata rather than pip freeze
|
|
|
|
|
|
2019-07-26 12:34:21 +00:00
|
|
|
* Fri Jul 26 2019 Miro Hrončok <mhroncok@redhat.com> - 0-5
|
|
|
|
|
- Allow to fetch test dependencies from tox
|
2019-07-26 15:50:36 +00:00
|
|
|
- Add %%tox macro to invoke tests
|
2019-07-26 12:34:21 +00:00
|
|
|
|
2019-07-26 11:47:03 +00:00
|
|
|
* Fri Jul 26 2019 Fedora Release Engineering <releng@fedoraproject.org> - 0-4
|
|
|
|
|
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
|
|
|
|
|
|
2019-07-02 14:53:05 +00:00
|
|
|
* Tue Jul 02 2019 Miro Hrončok <mhroncok@redhat.com> - 0-3
|
|
|
|
|
- Add %%pyproject_buildrequires
|
|
|
|
|
|
2019-07-02 12:02:54 +00:00
|
|
|
* Tue Jul 02 2019 Miro Hrončok <mhroncok@redhat.com> - 0-2
|
|
|
|
|
- Fix shell syntax errors in %%pyproject_install
|
|
|
|
|
- Drop PATH warning in %%pyproject_install
|
2019-07-02 10:41:04 +00:00
|
|
|
|
|
|
|
|
* Fri Jun 28 2019 Patrik Kopkan <pkopkan@redhat.com> - 0-1
|
|
|
|
|
- created package
|
