Learn more about these different git repos.
Other Git URLs
I'd like to set automation in place to build new package releases from PyPI in @copr/PyPI. The repository was created using a new tool, pyp2spec, which utilizes the pyproject-rpm-macros to create deterministic specfiles. Currently, when you want to build from PyPI, you can only use pyp2rpm. Newly there would be a possibility to choose between the tools. For the purposes of the Copr, pyp2spec is invoked like this: pyp2spec <pypi-package-name> --fedora-compliant --top-level where --fedora-compliant performs a check whether the package license is among the allowed ones (AFAIK mandatory for Copr contents as well) and --top-level indicates to perform an import test of only the top-level modules found in the package (avoids breakage when additional modules depending on GUI or handling different OSs' would be imported). The script's output is a specfile. pyp2spec is - for now - only compatible with Fedoras and EPEL 9. There is no template to choose from. It only works for Python 3. pyp2spec is ATM available in its copr.
pyp2spec <pypi-package-name> --fedora-compliant --top-level
--fedora-compliant
--top-level
Once it's possible to choose the build using pyp2spec and the packages are set to build with this method, new package releases on PyPI should trigger the automatic rebuild of those packages.
Thanks for the issue, valid request.
Before we implement this, the actual work-around is to setup the needed automation using the "custom method". Or are there some missing bits that are blocking you?
Metadata Update from @praiskup: - Issue tagged with: RFE
I face a few issues which I don't know how to solve to make it work automatically (I already use custom method in the repository): 1) pyp2spec is built in its Copr for Fedoras 35-37, but I can't use it as external repository to build the source RPM, see: https://copr.fedorainfracloud.org/coprs/ksurma/very-testy-one/build/4440470/ I work around this issue by adding the actual path to pyp2spec RPM as "build dependency", but it's not feasible for automation - with every new release the URL has to be updated. 1a) Side note: if I actually try to use pyp2spec from the Copr to build package for Fedora Rawhide (provided that I already have SRPM built), RPM build fails with 404 as it attempts to find repo for fedora-37 rather than fedora-rawhide: https://download.copr.fedorainfracloud.org/results/ksurma/very-testy-one/fedora-rawhide-x86_64/04440467-python-botocore/builder-live.log.gz
Possible solution: adding pyp2spec to Fedora; but it would be nice to have Copr smoothly integrated with itself.
2) Copr-PyPI relation. My copr's python-pyparsing is the same as pyparsing on PyPI but it looks like Copr doesn't know about it. Can this be connected (and how) within the current possibilities?
python-pyparsing
pyparsing
"using packages from Copr project itself for building SRPMs"
This indeed isn't possible by default. There's no relation between the source RPM chroot, and the buildroots (source RPM chroot might be a completely different chroot from the selected target chroots). We would have to add a new option for "external repositories" for source RPM. But not before #534 I'm afraid.
The sanest way to go here is to have pyp2spec in Fedora.
1a) 404 error
That's because $releasever expands to a number: https://download.copr.fedorainfracloud.org/results/ksurma/pyp2spec/fedora-$releasever-$basearch/
$releasever
https://download.copr.fedorainfracloud.org/results/ksurma/pyp2spec/fedora-$releasever-$basearch/
You could use https://download.copr.fedorainfracloud.org/results/ksurma/pyp2spec/$chroot/ instead.
https://download.copr.fedorainfracloud.org/results/ksurma/pyp2spec/$chroot/
2) Copr <=> PyPI relation
Indeed. The thing (discussed off-line) is that the anytia rebuilds are possible only with the PyPI source method currently.
Please see PR#2218
Commit 568f31e fixes this issue
Log in to comment on this ticket.