poetry should be offered as python version-specific packages rather than as variants

[LucaFilipozzi (Luca Filipozzi)]

If a user wishes to install both py37 and py38 (for whatever reason, testing, etc.), if there's a need to use poetry, then it should be installable as py37-poetry (providing poetry-3.7) and py38-poetry (providing poetry-3.8), with poetry selectable via port select.

[reneeotten (Renee Otten)]

In the future, please add the maintainer to CC (port info --maintainer poetry).

[LucaFilipozzi (Luca Filipozzi)]

I filed this ticket in response to to ticket:62295.

[ryandesign (Ryan Carsten Schmidt)]

Implementing this suggestion is required to fix comment:ticket:62682:4.

[harens (Haren S)]

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 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 ​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. ​commitizen, ​py-rich, etc.). I'm therefore in favour of keeping the variants rather than switching to python version-specific packages for the time being.

[harens <harensdeveloper@…>]

In 76360a866a862b93a7329952bbc40281bf93a19d/macports-ports (master):

py-dns-lexicon: remove poetry dependency

See #62297
See #62296
Closes #62682

• Remove py-future dependency and fix setuptools category
• Simplify symlink
• Unpin py36 version