[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