3 ms·
On the one hand, you are totally right, GitHub Actions are the VS Code of automation. People choose them because they are broke, they work well enough, and the
by doctorpangloss 2y ago
On the one hand, you are totally right, GitHub Actions are the VS Code of automation. People choose them because they are broke, they work well enough, and the average person chooses things based on how it looks. GitHub Actions looks easy, it's cozy, it's comfy, VS Code looks like a code editor, everything has to be cozy and comfy.
On the other hand, considering all of that, you can see why Python would arrive at this design. They are the only other people besides NPM who regularly have supply chain attack problems. They are seemingly completely unopinionated about how to fix their supply chain problems, while being opinionated about the lack of opinions about packaging in general. What is the end goal? Presumably one of the giant media companies, Meta, Google or Microsoft maybe, have to take over the development of runtime and PEP process, but does that even sound good?
- LtWorf 2y agoI think the end goal is to only allow github/google whatever accounts to publish code on Pypi, so importing whatever will be USA-sanctions safe. The burden to ban russians/koreans/iranians will be on those big companies and pypi will be able to claim they respect the rules without having the resources themselves to ban accounts from sanctioned countries. So in my opinion, in the future tooling will have some option to check if the software was uploaded via microsoft et al and can be considered unsanctioned in USA. Or they might just say that's how you upload now and that's it.
- doctorpangloss 2y ago> so importing whatever will be USA-sanctions safe... You are talking about guys who can barely figure out how to structure a Python package repository. They are not doing this kind of 4D chess. And anyway, none of that makes any sense.
- LtWorf 2y agoThe people paying for this, not them.
- woodruffw 2y agoNone of this is true. There is no plan to disable API token uploads to PyPI or to mandate Trusted Publishing, much less attestations. It's entirely intended to be a misuse-resistant way to upload to the index in the "happy case" where the package uses a CI/CD workflow that supports OpenID Connect. (I'm disappointed by the degree to which people seem to gleefully conspiracize about Python packaging, and consequently uncritically accept the worse possible interpretation of anything done to try and improve the ecosystem.)
- LtWorf 2y agoI don't think you can predict the future any more than me.
- doctorpangloss 2y agoI understand the desire to raise awareness about your fringe concern. But it makes no sense.
- woodruffw 2y agoI don't baselessly speculate about it. But yes, I do think I can predict with some confidence that PyPI is not going to remove API token access.
- zahlman 2y ago>(I'm disappointed by the degree to which people seem to gleefully conspiracize about Python packaging, and consequently uncritically accept the worse possible interpretation of anything done to try and improve the ecosystem.) I sympathize, but there are obvious reasons for this: low trust in the Python packaging system generally (both because of recent PSF activity and because of the history of complications and long-standing problems), and the fact that many similar things have been seen in the Linux and open-source worlds lately (for one example, Linux Mint's new stance on Flatpak and how they present Flatpak options in the Software Manager). (Edit: it also kinda rhymes with the whole "Secure Boot" thing and how much trouble it causes for Linux installation.)
- 2y ago