https://bugzilla.redhat.com/show_bug.cgi?id=2257921 --- Comment #14 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- (In reply to Sandro from comment #10) > That statement confused me. Does Versioneer honor > SETUPTOOLS_SCM_PRETEND_VERSION? I searched through the code and didn't find > any mention of it. There is an open issue requesting support for an override > by environment variable: No, the problem was that my brain was temporarily broken. You’re correct about Versioneer. > For the rest of the discussion regarding Versioneer, I believe we had a > similar debate before. Somehow, I thought using the packaged Versioneer > would allow me to omit expanding on the license. I mean, it *is* a minor quibble, as license issues go, and there is probably an argument that some kinds of _version.py (the ones without substantial code) are potentially too simple and mechanical to be copyrightable in most jurisdictions, but the "License" section of the README does say: To make Versioneer easier to embed, all its code is dedicated to the public domain. The _version.py that it creates is also in the public domain. Specifically, both are released under the "Unlicense", as described in https://unlicense.org/. Older versions have the same text, but specify CC0-1.0. Now, one could probably make some arguments about interpretation and intent, as this text somewhat wrongly conflates these ultra-permissive licenses with a pure public domain dedication, but it seems safest and simplest to just take the statement at face value: the generated _version.py is under the same license as Versioneer, which is Unlicense or CC0-1.0 depending on version. (If I remember correctly, even older versions of Versioneer were LicenseRef-Fedora-Public-Domain.) > I wish we could get a global exception not having > to bother with Versioneer's license... I wish upstreams would just stop using it. It was clever in its day, but tools like setuptools_scm and hatch-vcs are less messy and invasive. > By "broken the import" are you referring to the import statement above? > Because for me `%pyproject_check_import` works either way. Right, I just mean that something, somewhere *could* want to import that module. (In reply to Sandro from comment #11) > It turned out upstream's Versioneer config is broken. Looks like > medimages4tests may have started out as a partial copy of xnat4tests with > versioneer.py copied, but not the stuff it generates when installed. > > I sent a PR upstream. If that gets merged I can make another post-release > including that commit as well. > > Spec URL: https://fedorapeople.org/~gui1ty/review/python-medimages4tests.spec > SRPM URL: > https://fedorapeople.org/~gui1ty/review/python-medimages4tests-0.5. > 7%5e20250417gitc0a06fa-1.fc43.src.rpm The spec-file changes here look great at a glance. I’ll take a closer look at the details. -- 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=2257921 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202257921%23c14 -- _______________________________________________ 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
