https://bugzilla.redhat.com/show_bug.cgi?id=2221739 --- Comment #3 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- (In reply to Sandro from comment #1) > But I have a question regarding the Versioneer > foo applied in the spec file: > > Is this package specific? If so, what does the package do with/to Versioneer > that makes it necessary to have an elaborate bcond in the spec file? If not, > is this what we are doomed to apply to every package using Versioneer? I > hope not, since Versioneer is a pain as it is and this would be like a salty > bandaid on top. It *is* package specific, in that: - the __init__.py calls a function “get_version” from the generated _version.py: https://github.com/wtclarke/pymapvbvd/blob/0.5.4/mapvbvd/__init__.py#L2-L3 - only recent versions of versioneer generate a _version.py with that function - most packages don’t use “get_version” - most packages don’t require versioneer at all when building from the PyPI sdist - the fact that “export PYTHONPATH="${PWD}"” is required to use the bundled versioneer is weird, and this is the first time I‘ve seen it In Rawhide, I wanted to use the system versioneer because the package supports it—but I couldn’t do this in older Fedora releases or EPEL9 because the system versioneer was too old. (As noted, this is the first package I have ever found that cares about the version of versioneer!) After importing the package, I intend to remove the conditional and let the git branches diverge, which will make the spec file less messy-looking. It really seems like almost every versioneer-using package manages to find a slightly idiosyncratic way to do it. > This package at least has an up to date versioneer.py (0.28). That should > work across all branches. Why bother with the system provided version at all? Basically, I was optimizing for Rawhide, which can get by with just “rm -v versioneer.py” and will thus be very simple once the conditionals are dropped. I also considered that a lot of mucking around with PYTHONPATH is required to used the bundled versioneer in this particular package, and I would like to avoid that in the long term. Finally, although I’m generally less willing to go to great lengths to remove bundled sources that don’t directly contribute to the binary RPM contents, the fact that this lets us use a system tool instead of a bundled copy is also a benefit. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2221739 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202221739%23c3 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
