Packaging py-keyring
Mojca Miklavec
mojca at macports.org
Sat Feb 1 21:36:01 UTC 2020
Dear David,
On Sat, 1 Feb 2020 at 22:15, David Gilman wrote:
>
> I've been taking a stab at packaging poetry, a package manager for
> Python. It has a dependency on the py-keyring port which is
> maintained by reneeotten.
>
> The recent release of keyring v21 dropped support for Python before
> version 3.6. Renee came up with a clever trick in the portfile: if
> the py35-keyring is being requested, install v20, the last compatible
> version instead:
>
> https://github.com/macports/macports-ports/blob/master/python/py-keyring/Portfile
>
> However, the maintainers of poetry want to keep backwards
> compatibility with old versions of Python. They've explicitly pinned
> their dependency on v20 releases of keyring in order to keep poetry
> running on old Pythons. If I want poetry to use the existing v20
> keyring I'll have to explicitly depend on python35 for everything
> which is a non-goal.
The way you explained it, I would assume that poetry developers use
v20 releases for their own purposes, but you didn't explicitly mention
whether v21 is in fact incompatible with the latest version.
I assume you wouldn't even be asking this if v21 was compatible, but
then again, I would expect from developers that while they might be
using v20 by default in their workflow, they should at least attempt
to remain compatible with the latest release of their dependencies (or
they might just as well declare to be compatible with python 2.7 only
...).
Various distributions cannot afford to stick with zillions of versions
of ancient packages for the same software (unless one goes the route
of npm and simply installs the full ecosystem and a 1 GB bundle of
packages for each tiny website separately).
> Does anyone have any suggestions on how the py-keyring package can be
> changed to support all of this? I can copy the entire Portfile and
> rename it py-keyring20 and depend on that but I wonder if there's a
> way to extend the existing Portfile.
You could probably create a subport like py38-keyring20 inside
py-keyring. But it would make sense to figure out whether there's no
way to convince upstream to remain compatible with the latest release.
Mojca
More information about the macports-dev
mailing list