https://bugzilla.redhat.com/show_bug.cgi?id=2038159
--- Comment #4 from Ben Beasley <code(a)musicinmybrain.net> ---
(In reply to Major Hayden 🤠 from comment #2)
- At first, I was going to ask about using %forgemeta, but I see
that
there's no setup.py in the repo. 😉
The GitHub tarball would be fine. We can build straight from pyproject.toml
using pyproject-rpm-macros or anything that understands PEP 517[1]; the
setup.py is just for legacy use. On the other hand, there are some reasons to
prefer a PyPI sdist when it’s usable. For example, some projects have weird
release processes such that the GitHub archives have unexpected version numbers
in their metadata, and it’s easy to miss these. Usually I end up picking the
GitHub archive because the PyPI sdist is missing some tests or documentation,
but that’s not the case here.
----
The “forge” macros have their advocates and their detractors[2]. I’ve often
used them and recommended them, but I too have started to feel that it’s often
simpler not to use them, e.g.
URL:
https://github.com/foo/bar
Source0: %{url}/archive/v%{version}/bar-%{version}.tar.gz
They *do* make it simpler to build the snapshot information field when
packaging from a particular git commit rather than a release or tag, but it
turns out they’re not doing it in the currently-recommended way[3], so I’ve
even been gradually switching those packages away from these macros.
[1]
https://www.python.org/dev/peps/pep-0517/
[2]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[3]
https://bugzilla.redhat.com/show_bug.cgi?id=2048362
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2038159