[deleted]
PYX: The next step in Python packaging
321–330 of 479 posts
Re: PYX: The next step in Python packaging
#322>Modern I'll pass. I'd rather have the battle-tested old thing, thanks.
uv is battle tested
It's the default installation path for aider, for instance.
Re: PYX: The next step in Python packaging
#323`uv` is incredible software and I love it. I am willing to try anything from this team.
Re: PYX: The next step in Python packaging
#324All python packaging challenges are solved. Lesson learned is that there is not a single solution for all problems. getting more strings attached with VC funded companies and leaning on their infrastructure is a high risk for any FOSS community.
I see VC money as an artificial force propping up a project. It is not bad per se, but VC money is not a constant and it leaves a big drop at the end. If there is a big enough community that has grown around the project, that drop might be okay.
Re: PYX: The next step in Python packaging
#325This industry is fucking doomed.
Re: PYX: The next step in Python packaging
#326My 2c when it comes to python packaging:
1. do dev in an isolated environment like docker
2. install deps from config - ie. build a new image when adding a dep
Re: PYX: The next step in Python packaging
#327Earlier quoted context omitted.
What's wrong with just using virtualenv. I never used anything else, and I never felt the need to. Maybe it's not as shipping l shiny as the other tools, but it just works.
The problem is you can do whatever you want in it, and then have no way of reproducing that. pyproject.toml tries to fix it, poetry kept wanting to use their own wonky names for the tags, I'm not sure why. Once that is standardized, venvs should be cattle and not pets. That is all that is needed. UV makes that fast by hardlinking in the libraries and telling you the obvoius (that venvs should be cattle and not pets)…
I think poetry “lost” because they had to build ahead of the PEPs that standardized their way of doing things. I don’t think uv could exist without the work the poetry people put in, it served as a pretty powerful demonstration of the fact that better python packaging was possible.
Re: PYX: The next step in Python packaging
#328I've been burned too many times by embracing open source products like this. We've been fed promises like these before. They will inevitably get acquired. Years of documentation, issues, and pull requests will be deleted with little-to-no notice. An exclusively commercial replacement will materialize from the new company that is inexplicably missing the features you relied on in the first place.
This is a valid concern, but astral just has an amazing track record. I was surprised to see the community here on HN responding so cautiously. Been developing in python for about a decade now- whenever astral does something I get excited!
Frankly, it’s weird. You can find this business model all over the open-source world but for some reason Astral in particular is singled out for way more criticism on this than anything else I’ve seen, despite being unambiguously great contributors who have never put a foot wrong as far as I can tell.
Microsoft – who invented embrace, extend, and extinguish – own NPM, but I don’t see people wringing their hands over them in every thread that mentions NPM. But you mention Astral here or on Reddit and people line up to tell you it’s only a matter of time before they fuck people over. Why the disparity?
Re: PYX: The next step in Python packaging
#329Earlier quoted context omitted.
Node ecosystem still has the problem where if you try to build a project two years later, chances are good it won't work, because breaking changes are so common, and this is then multiplied across all the tiny packages that are dependencies of your dependencies.
Don't lockfiles help?
deps are delisted from npm and versions can be deleted
Re: PYX: The next step in Python packaging
#330I've been burned too many times by embracing open source products like this. We've been fed promises like these before. They will inevitably get acquired. Years of documentation, issues, and pull requests will be deleted with little-to-no notice. An exclusively commercial replacement will materialize from the new company that is inexplicably missing the features you relied on in the first place.
For what it's worth, I understand this concern. However, I want to emphasize that pyx is intentionally distinct from Astral's tools. From the announcement post: > Beyond the product itself, pyx is also an instantiation of our strategy: our tools remain free, open source, and permissively licensed — forever. Nothing changes there. Instead, we'll offer paid, hosted services that represent the "natural next thing you ne…
This is the way it's worked for PHP's composer packages, and it's worked well.