Hi Simon,
On Sat, Dec 28, 2024 at 10:33:28AM +0100, Simon Josefsson wrote:
> Thank you - I agree and hope to convince upstream PQconnect to pick build
> dependencies in a better way. This was a bit further down the dependency
> stack, but hopefully they can help anyway. They brought up a valid concern:
> prefer not to depend on things not on PyPI and I agree (of course, within
> reason). It seems unshare is there: https://pypi.org/project/unshare/
Everyone has their own kink. I ignore Python modules that are not in
Debian and others ignore Python modules not on PyPI.
My reasons for ignoring PyPI:
* It has a history of hosting malware.
* It has a history of hosting low-quality modules (such as the one you
are packaging).
* It tends to have multiple competing modules for a usecase. Each of
them has their own downsides and the good solution ends up not being
uploaded to PyPI.
* Modules come and go often only ever receiving a single upload and
your dependency ends up becoming technical debt.
* It has made uploading stuff harder and harder while simultaneously
degrading security by stopping support for pgp signatures.
* Accessing PyPI has become harder since it became "protected" by
fastly.
* Salvo Tomaselli gave a talk in Toulouse with more reasons.
I no longer consider PyPI worth my time. I have no objections to someone
else uploading linuxnamespaces to PyPI.
I note that you can also do optional dependencies. pqconnect may try
importing unshare and fall back to linuxnamespaces. The linuxnamespaces
module does something similar for dbus where you may opt for dbussy or
jeepney depending on your preference. Alternatively, you may carry a
patch in your pqconnect packaging to swap out the unshare module.
In any case, I stand by my recommendation of not uploading a module of
such dubious value to Debian when objectively[1] better replacements
exist.
Helmut
[1] I think there is one aspect that unshare is better at than
linuxnamespaces and that's performance. However, creating thousands
of namespaces per second is a very unusual use case, so I consider
this irrelevant.
