[MacPorts] #62296: poetry should be offered as python version-specific packages rather than as variants
MacPorts
noreply at macports.org
Sun Apr 25 10:42:44 UTC 2021
#62296: poetry should be offered as python version-specific packages rather than as
variants
----------------------------+----------------------
Reporter: LucaFilipozzi | Owner: dgilman
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.6.4
Resolution: | Keywords:
Port: poetry |
----------------------------+----------------------
Comment (by harens):
> If a user wishes to install both py37 and py38 (for whatever reason,
testing, etc.)
Off the top of my head, I can't think of a practical reason why a user
would wish to do this since the CLT should be the same regardless.
> Implementing this suggestion is required to fix comment:ticket:62682:4.
In regards to `py-lexicon` (see #62295 and #62682), poetry shouldn't have
been a dependency in the first place. This has been dealt with upstream
and should be fixed in the next release (see
[https://github.com/AnalogJ/lexicon/pull/787 AnalogJ/lexicon#787] for more
details).
As discussed in #62682, both `poetry` and `py-poetry-core` should rarely
(if ever) be required as a dependency in a portfile. In the majority of
scenarios, upsteam just hasn't configured poetry properly on their end.
We already have many poetry ports that are working fine without ever
needing to reference poetry (e.g.
[https://ports.macports.org/port/commitizen/ commitizen],
[https://ports.macports.org/port/py-rich/summary py-rich], etc.). I'm
therefore in favour of keeping the variants rather than switching to
python version-specific packages for the time being.
--
Ticket URL: <https://trac.macports.org/ticket/62296#comment:7>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list