• Stop recommending PyPi as upstream for Debian Python packages?

    From Simon Josefsson@21:1/5 to Helmut Grohne on Thu Jan 2 10:00:01 2025
    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?

    I don't recall seeing arguments in favor of PyPi, but maybe they exist.

    Otherwise is there any objections to me updating

    https://wiki.debian.org/Python/LibraryStyleGuide?action=show&redirect=Python%2FPackaging#debian.2Fwatch

    which led me in the wrong way, and made me use PyPi as the upstream
    source for packages I look at?

    /Simon

    -----BEGIN PGP SIGNATURE-----

    iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ3ZToRQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFokLHAP9Y4bkkz6KvHRQ82SmWu0NG4mtqtcSD AusH+k8I5ZnXIAD+Ipjl8Tdp+eOaHRhaj7X/blTEpHW6TkuqeL2cl0jpUg0=
    =nXQB
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to Dominik George on Thu Jan 2 10:20:01 2025
    On Thu, Jan 02, 2025 at 10:03:59AM +0100, Dominik George wrote:
    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?

    Exactly.
    The reasons listed are for an app upstream, not for a module packager.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmd2WdUtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh R/QP/Ax7dSHuRRaAXnZq3aSKtA3KCXAVNqkGcBbNgeCw0Pu3WEx3zz2552AlpXcd LKZfUViGeBeWPCOHXQllAwKKQae0UN5f2fsiFJqPXm8NTantegiuVKDngc1jTRgs NfDoT/nSUDDM2L3z2HpwwGDFdvzUxUssaBuUnEV7jabMA+hGaKDV4OEnN3e9tc8k ypnN3xOnF2WED3pSkP63M9IEG0uhSvrcZh+lT883BVdq3OdX8x/AKtdjhK8BwdtY 9/clLfWp0vGFG8ZLO5GZldql9f1pwy6KfXFD6mV/s/NPO3WvFpuuhQiewVjEJ7i9 fJrV0Otic0/H4TkHK9eiOThqhKIQpD1ozi1nhB3RewbnkCCjpOTWo8/eL8xPD/Mn qmkf2upp0VaZXo3sE8uSbPzOwTvqbyB3b3WkPI5PJZs383di+vAMW2xUNdXjsjtn R/Iy6oISVwFI9ZLu/JqWxP0eZywlbht2Nvk2a0fdE7GAxX9+F9PF/aFn/SeIWxuy MpPgbkMal6OwPT+IIOD5ygEizk0sDEAq3vVHMrr+6mvT9EwOnUcmSb4Yp9Q72oh/ jKj9+gdlgcjpHp1h3m48Z/TDG1+VxVy7K4GiSeiDn+mkqkUeongdUDWQIVFJ9bWN bHssMx/Xq5uhsjFH7TMnndLcHtJlbGXETbXqDCB/5XWh/ZEx
    =HHDj
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dominik George@21:1/5 to All on Thu Jan 2 10:20:01 2025
    Hi,

    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?

    -nik

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to Simon Josefsson on Thu Jan 2 10:20:01 2025
    On Thu, Jan 02, 2025 at 09:51:45AM +0100, Simon Josefsson wrote:
    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?

    I think this conflates two mostly unrelated things and at least some of
    the listed reasons are not applicable to your question.
    And "I ignore Python modules that are not in Debian" solves everything
    already.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmd2WaQtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh BuEQAIr/GpLQ6wmjYKBiKOtuZMH7FxOdbr77YgHS2jOqhAexT0yUY6bt+beyoptF 0aZITmfRjyiV82e6sHMu5ngv7QCLQ8funVYsIOTRXtGHbEYPCksD0KrMXaQfyZpw aZs/h/Yx62O750aOBz5mF95ulskF+xKZgK7h41MpCsUHjV1M60bbokw/8uHTYoDO V7Lxt6GC6S3waUbVXhwwc8rvXbpIspMHJ10o6NSPDtkxSJH4pyuyONx82GS8ah6L 0QRcByLGovgiOiuvkC9wFRmKjKFBseLY11EMUhmPayE/jDF7mheKsMiGhksWW2y3 UI3doAxwmI+UgPY2P0o++78K9KG/Uj3mBl1aJSfJ/GTpALV3p8kSBnPdQDbaimUB nz4biApuML708lgZOBakRDhXXTiliVLUbEQMgbHCpiCTq7PjL5fhWhivFCsOZ67E hLc3Bm9EElHBYHkM1n/i1lhWRq/oPLXt83Jog3pXByzqdUs2SLgnxmLjY4NIz9ZF b1LIEuM1fcf9JcGSDV2Lwr/nsyYW89FY2CT/SD6j2dHIdIH/Ckp7hpCWa5oq0+Qs l2APv/+WmezEBR1r0sygbhMiX4vQp5SuhXVKyRB9k/2qLkfuhVsU0CfZIzu8wtwm 7sBqgn6Ijl7yQmwY008+2ScQng2xQiFEhNJa412ZGYkSCBAh
    =OubK
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)