py-dns-lexicon: do not check active variant of poetry port

[ryandesign (Ryan Carsten Schmidt)]

I noticed that we keep getting build failures on the buildbot for py37-dns-lexicon and ​py39-dns-lexicon because e.g.:

DEBUG: Active variants check for source-type install considers depends_fetch depends_extract depends_lib depends_build depends_run: python39 py39-cryptography py39-dnspython py39-future py39-requests py39-tldextract py39-yaml py39-beautifulsoup4 py39-pep517 py39-python-install poetry py39-poetry-core py39-wheel lexicon_select
DEBUG: poetry is installed with the following variants: +python38
DEBUG:   required: python39, forbidden: 
DEBUG:   rejected, because required variant python39 is missing
Error: Failed to configure py39-dns-lexicon: poetry must be installed with +python39.

Obviously we want to be able to build and provide binaries of this port and the other ports that depend on it and we want not to see repeated build failures on the buildbot so I would like this problem to be fixed.

Is it true that py39-dns-lexicon really requires the +python39 variant of poetry? (This check was added in [ac766b845482f27fd8e8254e77c5e37b7da6c285/macports-ports].) If so, then I agree with #62296 that poetry should be changed to py-poetry so that py39-dns-lexicon can depend on py39-poetry etc. On the other hand, if py39-dns-lexicon would have no problem using poetry even with its +python38 variant selected, then the active variant check should be removed from py-dns-lexicon.

Compare with py-pygmsh and py-cipheycore which depend on poetry but do not check its active variant.

[Schamschula (Marius Schamschula)]

I'm not too familiar with the inner workings of poetry. Poetry, like pip, would like to manage python packages. As such, I'd prefer to avoid using it under MacPorts.

Perhaps poetry doesn't care that it itself was built with a different version of python. However, I do recall that I had issues upgrading py39-dns-lexicon with a branch mismatched version of poetry. That could have had a different cause, but prompted me to add the active variant code.

[harens (Haren S)]

I don't think py-dns-lexicon requires poetry as a build dependency in the first place, although please let me know if I've missed something here. Ever since ​python-poetry/poetry#1975, assuming you're retrieving the files from PyPi, you can treat it as you would any other python package. This is since a standard setup.py is generated in the final product.

As an example, ​py-rich makes use of poetry, but it isn't actually required as a dependency (unless you use the GitHub PG, in which case things get tricky).

The reason I made use of poetry in py-cipheycore is since I needed to use the CLT to generate a ​source distribution. At least in this scenario, it didn't matter which python variant of poetry was used since the CLT was the same either way and produced the correct file.

[harens (Haren S)]

Having said all of that, upstream is making use of poetry over the ​recomended poetry-core, which could potentailly throw a spanner in the works of removing it as a build dependency (see ​pyproject.toml#L4).

It might be useful to recommend them to switch. See ​willmcgugan/rich#289 for an example.

[Schamschula (Marius Schamschula)]

I just looked at this one more time. poetry and py-poetry-core are both needed at this time. They should be built against the same Python branch.

For past discussion, see: ​https://github.com/AnalogJ/lexicon/issues/568

[ryandesign (Ryan Carsten Schmidt)]

Replying to Schamschula:

They should be built against the same Python branch.

If that is the requirement, then implementing #62296 is the solution.

[harens (Haren S)]

Replying to Schamschula:

I just looked at this one more time. poetry and py-poetry-core are both needed at this time.

That's true, but I don't think it's necessary on their side. I've sent a ​PR upstream that should hopefully address this issue, although it's hard to tell if it works or not since the tests fail for unrelated reasons. I'll wait for a response from the maintainers.

If the PR is merged, then the poetry port can be left as it currently stands. As mentioned in the ​poetry-core docs:

Once this [poetry-core] is present, a PEP 517 frontend like pip can build and install your project from source without the need for Poetry or any of it's dependencies.

This is how other poetry ports in MacPorts are dealt with, and it should hopefully be applicable here as well.

[harens (Haren S)]

The issue's been dealt with upstream, so neither poetry nor py-poetry-core should be required as a dependency from the next release. I'd be more than happy to help with updating the portfile closer to the time in order to close this ticket.

To prevent this sort of issue from happening again, generally speaking, there shouldn't be any ports that require poetry as a dependency (unless it's for the CLT in rare circumstances). The upstream projects should instead be encouraged to fix their poetry configuration as done with lexicon. I'll try and document all of this somewhere in the MacPorts wiki/guide some time in the future.

The same issue applies to py-pygmsh, which also hasn't been configured properly upstream. However, if the binaries are building fine for the moment, this can be dealt with later.

[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