Hide Forgot
Would it be possible to branch/build poetry for epel8? It's needed/wanted for the noggin stack (The new fedora account system) See: https://pagure.io/fedora-infrastructure/issue/9152 Happy to help/comaintain/etc.
My opinion: 1. Poetry moves pretty fast. Is it clever to package it for a system that supposes to be stable for many years? 2. The dependency stack is not trivial. 3. Poetry and some of the deps use pyproject macros in Fedora, hence the spec files would need to be rewritten in Fedora. Hence, I believe it would be easier to package noggin in EPEL from the generated sdist that IMHO contains a legacy setup.py file for exactly this purpose. Either way, if you'd like to branch poetry into epel anyway, and be the maintainer, no problem with that.
> would need to be rewritten in Fedora. Should have been: would need to be rewritten in EPEL.
(In reply to Miro Hrončok from comment #1) > My opinion: > > 1. Poetry moves pretty fast. Is it clever to package it for a system that > supposes to be stable for many years? Poetry itself moves fast, yes, but the pyproject.toml section data hasn't changed in years, and Poetry projects are all massively backwards compatible to the 0.12.x versions still by default. > 2. The dependency stack is not trivial. :( > 3. Poetry and some of the deps use pyproject macros in Fedora, hence the > spec files would need to be rewritten in Fedora. > The pyproject macros would still work on EL8 as long as you avoided dynamic buildrequires, wouldn't it? > Hence, I believe it would be easier to package noggin in EPEL from the > generated sdist that IMHO contains a legacy setup.py file for exactly this > purpose. > Noggin isn't getting tagged and released with generated source tarballs, which makes this option hard. :(
(In reply to Neal Gompa from comment #3) > (In reply to Miro Hrončok from comment #1) > > My opinion: > > > > 1. Poetry moves pretty fast. Is it clever to package it for a system that > > supposes to be stable for many years? > > Poetry itself moves fast, yes, but the pyproject.toml section data hasn't > changed in years, and Poetry projects are all massively backwards compatible > to the 0.12.x versions still by default. Good to hear. Hope it won't be backwards incompatible in 2029 thou :/ > > 3. Poetry and some of the deps use pyproject macros in Fedora, hence the > > spec files would need to be rewritten in Fedora. > > > > The pyproject macros would still work on EL8 as long as you avoided dynamic > buildrequires, wouldn't it? We have tried with Fedora 30. It was pain, so we decided not to support that. If somebody is willing to support the macros in EPEL 8 forever, I'm happy to help getting started, but the API is not stable yet and I don't want to end up backporting impossible stuff to EPEL 8 from Fedora 42 once the EPEL maintainers actually use the macros and start merging their master/epel8 branches back and forth. I'm not even sure RHEL 8 pip supports pyproject.toml properly. It is 9.0.3, so it does not support PEP 518 at all (but that's fine, because we cannot have dynamic buildrequires anyway). The support for PEP 517 was very fresh then (read: possibly not working). Pyproject macros are designed to work with state of the art of Python packaging (even if it means we need to adapt often). RHEL 8 is designed to be stable and it is already very old now. I am just not sure if this plays nicely together. But I don't know, maybe they would just work. It might however be easier to call poetry directly from the specs in EPEL 8. > > Hence, I believe it would be easier to package noggin in EPEL from the > > generated sdist that IMHO contains a legacy setup.py file for exactly this > > purpose. > > > > Noggin isn't getting tagged and released with generated source tarballs, > which makes this option hard. :( One option seem harder than the other. My opinion? Use setuptools in noggin if the target platform is RHEL 8. I realize that poetry is nice, but not sure if it's worth the trouble.
That all said, if somebody wants the EPEL 8 branch of poetry anyway, I'm fine with that. I recommend starting in copr to see how far we can get before requesting the branches.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.