5 ms·

It would be great if the author backed up, really, any of their points with some kind of demonstration about what they're talking about. This article otherwise

It would be great if the author backed up, really, any of their points with some kind of demonstration about what they're talking about. This article otherwise is seemingly a bunch of handwaving about vague "problems" that exist but without actually clearly stating examples. Also the author is flat out incorrect on this: > This decentralization however came with a lot of challenges and today decentralized package hosting is no longer supported by the Python ecosystem. pip has supported github urls for a long time. edit Further: > The second thing that became apparent over time was also that decentralized services came with a lot of security risks. Every one of those hosts allowed the re-publishing of already existing packages. Domains that lapsed could be re-registered by other people and new packages could be placed there. Linux package management systems solved the decentralization "problem" years ago. It's why there's so many mirrors available when you download packages. Signed packages, and even "trusted-source" checksums can provide for integrity in cases where decentralization exists. That some package managers threw this away in favour of monolithic repositories is kind of irrelevant to how ActivityPub works.

the_mitsuhiko 4y ago
Author here. > pip has supported github urls for a long time. setuptools used to be able to pull packages published to the index from external URLs. Support for this was removed many years ago. Also you cannot publish packages to PyPI that reference dependencies on GitHub. About the rest of your points on package indexes I believe I addressed them in the post already.
- BeefWellington 4y ago
  That's specific to one scenario for Python. It's hardly the entire ecosystem, which is my point. Decentralization is there already and well-supported in the provided tools. You just can't abuse the official PyPI sources, and that's a reasonable approach.
  - the_mitsuhiko 4y ago
    The point I was making is that systems have a tendency to centralize, even in the absence of a bad actor. Decentralization was really well supported in the Python ecosystem in former times, it no longer is. The trend is pretty self evident I would argue.
  - lmm 4y ago
    > It's hardly the entire ecosystem, which is my point. It is, de facto, the entire ecosystem. Everything's on PyPI, and if your package can't interoperate with PyPI then it will wither away very quickly.
    - cowsandmilk 4y ago
      From experience, that hasn’t been true. I’ll give an example. Rdkit[0] went for years without being able to be released via pypi and could only be installed easily via conda[1]. Despite this, it thrived enough as a project that users got its postgresql extension to be part of AWS Aurora[2] in 2020, which means wide adoption before rdkit had managed to figured out how to be distributed by pypi in 2021. There are open source projects like this all over the place, thriving outside the centralized repos. [0] https://rdkit.org https://rdkit.org [1] https://stackoverflow.com/questions/58199504/how-to-install-a-package-rdkit-from-conda-with-pip https://stackoverflow.com/questions/58199504/how-to-install-... [2] https://aws.amazon.com/about-aws/whats-new/2020/09/amazon-aurora-postgresql-supports-rdkit-extension/ https://aws.amazon.com/about-aws/whats-new/2020/09/amazon-au...
      - the_mitsuhiko 4y ago
        And yet, all popular projects move to PyPI over time which is in line with the point I was making.

the_mitsuhiko 4y ago

Author here. > pip has supported github urls for a long time. setuptools used to be able to pull packages published to the index from external URLs. Support for this was removed many years ago. Also you cannot publish packages to PyPI that reference dependencies on GitHub. About the rest of your points on package indexes I believe I addressed them in the post already.

BeefWellington 4y ago
That's specific to one scenario for Python. It's hardly the entire ecosystem, which is my point. Decentralization is there already and well-supported in the provided tools. You just can't abuse the official PyPI sources, and that's a reasonable approach.
- the_mitsuhiko 4y ago
  The point I was making is that systems have a tendency to centralize, even in the absence of a bad actor. Decentralization was really well supported in the Python ecosystem in former times, it no longer is. The trend is pretty self evident I would argue.
- lmm 4y ago
  > It's hardly the entire ecosystem, which is my point. It is, de facto, the entire ecosystem. Everything's on PyPI, and if your package can't interoperate with PyPI then it will wither away very quickly.
  - cowsandmilk 4y ago
    From experience, that hasn’t been true. I’ll give an example. Rdkit[0] went for years without being able to be released via pypi and could only be installed easily via conda[1]. Despite this, it thrived enough as a project that users got its postgresql extension to be part of AWS Aurora[2] in 2020, which means wide adoption before rdkit had managed to figured out how to be distributed by pypi in 2021. There are open source projects like this all over the place, thriving outside the centralized repos. [0] https://rdkit.org https://rdkit.org [1] https://stackoverflow.com/questions/58199504/how-to-install-a-package-rdkit-from-conda-with-pip https://stackoverflow.com/questions/58199504/how-to-install-... [2] https://aws.amazon.com/about-aws/whats-new/2020/09/amazon-aurora-postgresql-supports-rdkit-extension/ https://aws.amazon.com/about-aws/whats-new/2020/09/amazon-au...
    - the_mitsuhiko 4y ago
      And yet, all popular projects move to PyPI over time which is in line with the point I was making.