Bug 1898395 - poetry for epel8
Summary: poetry for epel8
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: poetry
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-16 23:08 UTC by Kevin Fenzi
Modified: 2021-02-18 23:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Kevin Fenzi 2020-11-16 23:08:33 UTC
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.

Comment 1 Miro Hrončok 2020-11-17 07:41:51 UTC
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.

Comment 2 Miro Hrončok 2020-11-17 07:45:02 UTC
> would need to be rewritten in Fedora.

Should have been: would need to be rewritten in EPEL.

Comment 3 Neal Gompa 2020-11-17 11:08:13 UTC
(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. :(

Comment 4 Miro Hrončok 2020-11-17 17:26:11 UTC
(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.

Comment 5 Miro Hrončok 2020-11-17 17:27:52 UTC
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.

Comment 6 Ben Cotton 2021-02-09 15:25:22 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.


Note You need to log in before you can comment on or make changes to this bug.