Packaging py-keyring

[David Gilman]

> 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<