> 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.
Pipenv is already in MacPorts (with 10 requested installs on MacPorts stats and only two of those are me!) and it does the same sort of job as Poetry does. I would be shocked if one was allowed in and another wasn't, and if you're seriously considering banning Poetry you probably also want to remove Pipenv from distribution. Both programs are used on the command line to manage the virtualenv for your projects. Their code bases are fully independent of your Python codebase, there is no `import poetry` or anything like that. The recommended Poetry installation is a great, pragmatic choice for newbies unfamiliar with good system administration practice - it gets them a quick, working installation that is unlikely to break on them. However, it is has the tradeoff that you now have a separate installation of Python software somewhere on your system, unmaintained and forgotten. The philosophy behind package managers like MacPorts is to avoid that situation entirely: everything installed on a system should be registered centrally to allow for easy installation, removal and timely software and security updates for the entire dependency graph. It's not wrong for Poetry's README to suggest what it does but Poetry definitely has a home in MacPorts. tl;dr Poetry exists outside of your software projects. It is installed and used globally and it makes sense to use MacPorts to manage Poetry like it does to use MacPorts for all the other globally installed software on your system. The fear with patching Poetry's setup.py to support post-v20 releases of py-keyring is that keyring's maintainers might chose to make hard, breaking, backwards-incompatible choices like `from __future__ import annotations` that would totally wreck compatibility with old releases of Python. However, if the MacPorts policy is to not to match Poetry's support for older Python 3.x releases the risk of that happening goes way down to the point where I'd be surprised if it is ever an issue. And finally the keyring API has only five functions. If there was a serious API-incompatible change to those you'll probably be packaging a keyring2 or doing something else to deal with the fallout across everything that depends on keyring anyway and Poetry will piggyback on whatever you do for that. -- David Gilman :DG<
