Post #2563325
2023-01-16 04:47 UTC
Replies (8)
-
@stargirl@hachyderm.io 2023-01-16 04:48
Go ahead and bookmark this so you can link to it every few months when another baby faced, naive, precious little developer thinks that they can slay the hydra because they only see one head.
-
@AlgoCompSynth@ravenation.club 2023-01-16 06:52
@stargirl@hachyderm.io They actually did the forbidden thing - re-invented the wheel. 😈
-
@greg@aus.social 2023-01-16 13:18
@stargirl@hachyderm.io Thanks for helping to explain why Python packaging seems so utterly bonkers broken to me, a web dev.
-
@sky@social.coop 2023-01-16 13:56
@stargirl@hachyderm.io We're doing something related to what you wrote in this threat at ActiveState, but our target audience is mostly enterprise customers. I agree that having a single packaging solution that works great for every use case is naive, but I don't see why each of them can't be "solved" "individually".
-
@corbin@defcon.social 2023-01-16 16:13
@stargirl@hachyderm.io #Nix offers a genuine solution and a path towards packages as capabilities. #nixpkgs has a mature #Python subsystem. No involvement with PSF is required.
-
@jbowen@mast.hpc.social 2023-01-19 21:17
@stargirl@hachyderm.io As much as I love Python, I hate the packaging "experience."
-
@AlgoCompSynth@mastodon.social 2024-08-07 01:56
@stargirl@hachyderm.io I'm firmly in the Anaconda (miniforge, actually) camp. With libmamba thankyouverymuch 😉
-
@nobody@mastodon.acm.org 2024-08-27 09:12
@stargirl@hachyderm.io Rephrasing @corbin@defcon.social, I'd say that "Python Packaging" is actually solved. Mostly. Everything-pyproject.toml (maybe with PEP-725) is comprehensive for what's truly in scope for "python packaging". There will necessarily be some native stuff that is absolutely out of scope for "python packaging", in fact most of it. There will always have to be a "system layer" under "python packages". Nixpkgs is one consumer that integrates PEP-compliant "python packages" with its "native" stuff