The versioning caps that poetry has seem very strict and at least in the case of keyring unnecessarily strict. I would definitely not want to create a “py-keyring20” (sub)port, because that effectively will mean you’ll have to create a new subport ever time upstream decides that they want to use another version. Right now this might only be an issue with keyring (and you should be able to just replace their required version), but this is bound to happen for other dependencies of poetry as well that have equally strict version caps.
I must say I am also not convinced we actually need to add another Python package manager, but perhaps there are use-cases I haven’t considered yet. I would say that if you want to use MacPorts to take care of you Python package, use it to handle your dependencies. If you want to use poetry to do so, you likely want to install it in their recommended way (i.e., "isolated from the rest of your system by vendorizing its dependencies” [1]) and don’t need MacPorts for that. Renee [1] https://python-poetry.org/docs/ > On Feb 1, 2020, at 7:16 PM, Ryan Schmidt <[email protected]> wrote: > > On Feb 1, 2020, at 16:01, David Gilman wrote: > >> So doing >> a sed on the poetry package metadata to allow it to use v21 of keyring >> is also a choice here and it might even work but has its own awful >> tradeoffs. > > Such as? (I'm not terribly familiar with python)
