> 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 poe
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
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)
> 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 j
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
> v
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
