Bug 1936448 - RFE: %pyproject_buildrequires `pip install -r <file>` equivalent
Summary: RFE: %pyproject_buildrequires `pip install -r <file>` equivalent
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pyproject-rpm-macros
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomáš Hrnčiar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-08 14:12 UTC by Miro Hrončok
Modified: 2021-07-17 01:50 UTC (History)
5 users (show)

Fixed In Version: pyproject-rpm-macros-0-43.fc35 pyproject-rpm-macros-0-43.fc34 pyproject-rpm-macros-0-43.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-08 14:55:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Miro Hrončok 2021-03-08 14:12:05 UTC
I'd like to be able to do:

    %pyproject_buildrequires -p requirements-test.txt

Where requirements-test.txt file would have pip-names and possibly versions in it.
The idea is to "simply" process the file line by line with the function that s currently named parse_tox_requires_lines in pyproject_buildrequires.py and add each them via requirements.extend(...).

Some projects don't use tox or extras for tests requirements, or they simply use such file from within tox (so using -p instead of -t saves a tox dependency).


The following (very interesting) code made me think of this:

https://src.fedoraproject.org/rpms/python-ryu/c/ea199b8eccaf03ac42762728362ca3b520a0b446

We should of course support passing multiple files.

Alternatively, this could be a standalone macro, used like this:

%generate_buildrequires
%pyproject_buildrequires -r
%pyproject_something requirements-test.txt

Comment 1 Miro Hrončok 2021-03-08 14:36:40 UTC
Having it as a separate macro would allow to use it for Python code that is not a Python package (for example for python3-docs).

Comment 2 Ben Beasley 2021-05-15 14:23:15 UTC
Thanks for suggesting this. I don’t know why I didn’t.

While I eventually chose to re-orphan python-ryu, I know there are other packages I would use this in if it were available.

> Some projects don't use tox or extras for tests requirements, or they simply use such file from within tox (so using -p instead of -t saves a tox dependency).

Agreed. It’s also common to see a requirements-doc.txt or similar. Here are a few examples of Python packages I maintain that fit this description in one way or another:

https://src.fedoraproject.org/rpms/python-starlette
https://src.fedoraproject.org/rpms/python-databases
https://src.fedoraproject.org/rpms/python-jose
https://src.fedoraproject.org/rpms/python-ncclient
https://src.fedoraproject.org/rpms/python-pgspecial
https://src.fedoraproject.org/rpms/python-pyrsistent

Unfortunately, usually a requirements.txt does things like pinning exact versions of linters and formatters. It also commonly includes a bunch of tools that are used in CI or for uploading to PyPI but are not needed by the RPM build; occasionally some of these are not packaged in Fedora. The packager will therefore have to filter it and/or loosen the version specifications, perhaps with sed or awk.

In some cases this is worthwhile, because there are a lot of actual BR’s in the file; and in others it’s still easier to just add the necessary BR’s manually, because there are so many things that must be filtered out. It’s not obvious that there’s any way to make this part easier or less ad-hoc in general. Something like this is likely to be a common pattern in practice:

> %generate_buildrequires
> %pyproject_buildrequires -r
> sed -r -e 's/==/>=/' -e '/autoflake/d' \
>     requirements-test.txt doc/requirements.txt > requirements-rpm.txt
> %pyproject_something requirements-rpm.txt

The suggested macro would still help a little in a lot of cases, and help a lot in a few cases.

Comment 3 Fedora Update System 2021-07-08 14:53:15 UTC
FEDORA-2021-62dc3365c6 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-62dc3365c6

Comment 4 Fedora Update System 2021-07-08 14:55:19 UTC
FEDORA-2021-62dc3365c6 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 5 Fedora Update System 2021-07-08 14:58:29 UTC
FEDORA-2021-5476e05676 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-5476e05676

Comment 6 Fedora Update System 2021-07-08 15:02:38 UTC
FEDORA-2021-cc2936539e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-cc2936539e

Comment 7 Fedora Update System 2021-07-09 01:52:47 UTC
FEDORA-2021-5476e05676 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-5476e05676`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-5476e05676

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2021-07-09 01:55:00 UTC
FEDORA-2021-cc2936539e has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-cc2936539e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cc2936539e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2021-07-17 01:38:23 UTC
FEDORA-2021-5476e05676 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Fedora Update System 2021-07-17 01:50:05 UTC
FEDORA-2021-cc2936539e has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.