I see the following errors in the build log of a fc36 build [1]:
ValueError: Globs did not match any module: pymunin
Going up it looks like the name of the package is not expanded and falls back to UNKNOWN:
Successfully built UNKNOWN
However, the builds for fc37 and rawhide did succeed. I also tried a local mock build for x86_64, but the result is the same.
I fail to grasp what's going on here.
[1] https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-36...
-- Sandro
On 05. 09. 22 19:00, Sandro wrote:
I see the following errors in the build log of a fc36 build [1]:
ValueError: Globs did not match any module: pymunin
Going up it looks like the name of the package is not expanded and falls back to UNKNOWN:
Successfully built UNKNOWN
However, the builds for fc37 and rawhide did succeed. I also tried a local mock build for x86_64, but the result is the same.
I fail to grasp what's going on here.
[1] https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-36...
Looking at the project https://pypi.org/project/PyMunin3/3.0.1/#files
They include metadata for setuptools in pyproject.toml only (PEP 621):
https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L5
This has only been supported since setuptools 61.0.0:
https://setuptools.pypa.io/en/latest/history.html#v61-0-0 https://peps.python.org/pep-0621/
On Fedora 36, setuptools is 59.6 and it does not read/understand the information from pyproject.toml.
Unfortunately, when no name or version is present, setuptools does the UNKNOWN==0.0.0 thing:
https://github.com/pypa/setuptools/issues/2329
My guess is that when PyMunin3 started to use this feature:
https://github.com/penguinpee/PyMunin3/commit/3993dcaa5366da9d771575e8735dd5...
They should have changed the minimal required setuptools version in:
https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L2
In fact: https://github.com/penguinpee/PyMunin3/pull/3
To package PyMunin3 on Fedora 36, you might need to revert 3993dcaa5366 via a patch or somebody would need to backport this feature to setuptools 59. That might be non-trivial. Due to a significant amount of other braking changes, updating setuptools in Fedora 36 to 61 is not very likely.
On 05. 09. 22 19:17, Miro Hrončok wrote:
My guess is that when PyMunin3 started to use this feature:
https://github.com/penguinpee/PyMunin3/commit/3993dcaa5366da9d771575e8735dd5...
They should have changed the minimal required setuptools version in:
https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L2
In fact: https://github.com/penguinpee/PyMunin3/pull/3
To package PyMunin3 on Fedora 36, you might need to revert 3993dcaa5366 via a patch or somebody would need to backport this feature to setuptools 59. That might be non-trivial. Due to a significant amount of other braking changes, updating setuptools in Fedora 36 to 61 is not very likely.
Apologies, I now realized that @penguinpee is you. In that case, you might consider not using this feature until Fedora 36 goes EOL.
On 05-09-2022 19:17, Miro Hrončok wrote:
On 05. 09. 22 19:00, Sandro wrote:
I see the following errors in the build log of a fc36 build [1]:
ValueError: Globs did not match any module: pymunin
Going up it looks like the name of the package is not expanded and falls back to UNKNOWN:
Successfully built UNKNOWN
However, the builds for fc37 and rawhide did succeed. I also tried a local mock build for x86_64, but the result is the same.
I fail to grasp what's going on here.
[1] https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-36...
Looking at the project https://pypi.org/project/PyMunin3/3.0.1/#files
They include metadata for setuptools in pyproject.toml only (PEP 621):
https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L5
This has only been supported since setuptools 61.0.0:
https://setuptools.pypa.io/en/latest/history.html#v61-0-0 https://peps.python.org/pep-0621/
On Fedora 36, setuptools is 59.6 and it does not read/understand the information from pyproject.toml.
Unfortunately, when no name or version is present, setuptools does the UNKNOWN==0.0.0 thing:
https://github.com/pypa/setuptools/issues/2329
My guess is that when PyMunin3 started to use this feature:
https://github.com/penguinpee/PyMunin3/commit/3993dcaa5366da9d771575e8735dd5...
They should have changed the minimal required setuptools version in:
https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L2
In fact: https://github.com/penguinpee/PyMunin3/pull/3
To package PyMunin3 on Fedora 36, you might need to revert 3993dcaa5366 via a patch or somebody would need to backport this feature to setuptools 59. That might be non-trivial. Due to a significant amount of other braking changes, updating setuptools in Fedora 36 to 61 is not very likely.
Thank you, Miro, for the explanation and the pull request. I remember switching away from setup.cfg after being told that pyproject.toml is the way forward. I must have missed the fact that this required a newer minimum version of setuptools.
Since this package has yet to make its way into Fedora, I don't mind if it's not available for F36. It will trickle down (or is it up?) from F37.
-- Sandro
On Mon, Sep 5, 2022 at 2:01 PM Sandro lists@penguinpee.nl wrote:
Thank you, Miro, for the explanation and the pull request. I remember switching away from setup.cfg after being told that pyproject.toml is the way forward. I must have missed the fact that this required a newer minimum version of setuptools.
pyproject does not work well, and is not backwards compatible. This is particularly a problem for EPEL ports from Fedora. Personally, I'd like to see it fixed for EPEL before relying on it for anything in Fedora.
On Mon, Sep 5, 2022 at 2:01 PM Sandro <lists(a)penguinpee.nl> wrote:
pyproject does not work well, and is not backwards compatible. This is particularly a problem for EPEL ports from Fedora. Personally, I'd like to see it fixed for EPEL before relying on it for anything in Fedora.
The current py packaging guidelines recommend the opt-in dependency generator (which uses pyproject.toml) unless EPEL 8 or non-current Fedoras are used. Should this caveat be extended to F36 and EPEL 9, or am I mis-understanding the role of pyproject.toml for the packaging macros?
On 06. 09. 22 16:52, Michael J Gruber wrote:
On Mon, Sep 5, 2022 at 2:01 PM Sandro <lists(a)penguinpee.nl> wrote:
pyproject does not work well, and is not backwards compatible. This is particularly a problem for EPEL ports from Fedora. Personally, I'd like to see it fixed for EPEL before relying on it for anything in Fedora.
The current py packaging guidelines recommend the opt-in dependency generator (which uses pyproject.toml) unless EPEL 8 or non-current Fedoras are used. Should this caveat be extended to F36 and EPEL 9, or am I mis-understanding the role of pyproject.toml for the packaging macros?
This is explicitly about project metadata (name, version, etc.) in pyproject.toml a new feature of setuptools.
The macros use pyproject.toml for different purpose and don't need this feature unless upstream uses it.
On Tue, Sep 6, 2022 at 10:52 AM Michael J Gruber mjg@fedoraproject.org wrote:
On Mon, Sep 5, 2022 at 2:01 PM Sandro <lists(a)penguinpee.nl> wrote:
pyproject does not work well, and is not backwards compatible. This is particularly a problem for EPEL ports from Fedora. Personally, I'd like to see it fixed for EPEL before relying on it for anything in Fedora.
I believe that was quoting me?
The current py packaging guidelines recommend the opt-in dependency generator (which uses pyproject.toml) unless EPEL 8 or non-current Fedoras are used. Should this caveat be extended to F36 and EPEL 9, or am I mis-understanding the role of pyproject.toml for the packaging macros?
If possible, I'd much rather see backports to RHEL 8 and RHEL 9 completed to ease backporting before any further python modules whatsoever get pyproject activated in Fordera. Grabbing a current Fedora release of anything with pyproject and backporting it to RHEL is now a serious pain in the keister.