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.
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:
[long list of arguments]
I somehow don't get the point here.
Usually, I don't get to choose my build dependencies, so if an
application I want to package depends on some module, I will have to
package it. What point is there in discussing whether PyPI has a lot of
crap around it, or whether it is a bad dependency? If an application I
am packaging depends on a module and that module is low-quality or
malware, what point is there in pulling it from GitHub instead?
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:
[long list of arguments]
Context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091506#27
Helmut Grohne <helmut@subdivi.de> writes:
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 am beginning the feel the same.
Is there anyone in the Debian Python team who feels PyPi is preferrable?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 483 |
Nodes: | 16 (2 / 14) |
Uptime: | 86:56:50 |
Calls: | 9,578 |
Files: | 13,666 |
Messages: | 6,143,532 |