Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PYX: The next step in Python packaging

astral.sh

Post reply on HN
Print view View original

291–300 of 479 posts

Re: PYX: The next step in Python packaging

#291

Post by megamix »

joshdavham wrote: post #283
megamix wrote: post #266

No Thanks. For majority of my use case pip is just fine. I’m not here to chase time just to live life

This is a low quality comment. From the guidelines [1] > Please don't post shallow dismissals, especially of other people's work. [1] https://news.ycombinator.com/newsguidelines.html

Thanks for pointing that out. You could also say it’s a condensed high entropy comment. Anyway I’ll outline a more thorough dismissal.

Edit: and turns out a smart guy is top rated comment atm

"All 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."

Re: PYX: The next step in Python packaging

#292

Post by megamix »

fastball wrote: post #270
megamix wrote: post #266

No Thanks. For majority of my use case pip is just fine. I’m not here to chase time just to live life

Strange to reject something when you don't even understand what it is. PYX is a package registry , and therefore an alternative to PyPI (like how JSR is an alternative to NPM). The alternative to `pip` that Astral has built is called `uv`. Feel free to not use that either, but personally I'd consider it if I were you. It has full pip compatibility (with significantly more speed), and many other nice features besides.

Yes, it still follow the same PEP standard no? So why would I invest in something like that and I’m never impressed by “speed improvements”. uv high speed infrastructure is not really what is my bottleneck in projects.

Re: PYX: The next step in Python packaging

#293

Post by fastball »

megamix wrote: post #292
fastball wrote: post #270

Earlier quoted context omitted.

Strange to reject something when you don't even understand what it is. PYX is a package registry , and therefore an alternative to PyPI (like how JSR is an alternative to NPM). The alternative to `pip` that Astral has built is called `uv`. Feel free to not use that either, but personally I'd consider it if I were you. It has full pip compatibility (with significantly more speed), and many other nice features besides.

Yes, it still follow the same PEP standard no? So why would I invest in something like that and I’m never impressed by “speed improvements”. uv high speed infrastructure is not really what is my bottleneck in projects.

Two other major benefits besides speed were listed in the opening paragraph about why you might want to use PYX.

Likewise with uv, speed is only one of the (many) improvements over pip.

Re: PYX: The next step in Python packaging

#295

Post by unmole »

mnazzaro wrote: post #139
monster_truck wrote: post #10

I'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!

HN comments default to cynisim.

Re: PYX: The next step in Python packaging

#296

Post by notpushkin »

woodruffw wrote: post #50
notpushkin wrote: post #38

Earlier quoted context omitted.

Correct; however, without a CLA and assuming there are outside contributors, relicensing the existing code would be mildly painful, if not downright impossible.

You're saying that would be more painful in a viral license setting, right? If so I agree, although I think there's a pretty long track record of financially incentivized companies being willing to take that pain. MongoDB's AGPL transition comes to mind. But, to refocus on the case at hand: Astral's tools don't require contributors to sign a CLA. I understand (and am sympathetic) to the suspicion here, but the bigger…

Yeah, only the (viral license + no CLA) combo has this effect of preventing you from changing license down the road. In your case (permissive license, no CLA) you still can relicense uv or Ruff. Not saying that you will do it, of course :-)

I do like your strategy, hope it works out!

Re: PYX: The next step in Python packaging

#297

Post by gnubee »

Isn't all of this solved with containers (or virtual machines)? Just lxc/lxd/docker a new container, and no more worries about virtual environments or conda or whatever other bandaids. A container per project. A container per version of a project. Heck, a container per package in a project!

Re: PYX: The next step in Python packaging

#298

Post by isodev »

almostgotcaught wrote: post #258
iepathos wrote: post #243

Earlier quoted context omitted.

Human naming has nothing to do with software naming which seems obvious but apparently not. Python package creators should check the pypi registry for names and generally avoid name collisions where reasonable. Common sense applies for reduced confusion for users globally and also for potential legal issues if any party trademarks their software name. What makes one pyx more real than the other is one was first and t…

> https://pypi.org/project/PyX/ the last release is Oct 16, 2022. are we doing this like jerseys - the name is now retired because pyx won all the championships?

What are you suggesting? All packages do an annual release with a new beautiful section in their README to justify their existence?

Re: PYX: The next step in Python packaging

#299

Post by physicsguy »

woodruffw wrote: post #19
monster_truck wrote: post #10

I'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…

Conda said all this as well, and solved the same issues you’re trying to - namely precompiled versions of difficult to build packages. It then went commercial.

In the HPC space there are already Easybuild and Spack which make all the compiler tool chain and C and Fortran library dependency stuff very easy. They just haven’t taken off outside as they aim to solve cluster management problems but Spack is easy to self serve.

Re: PYX: The next step in Python packaging

#300

Post by rcleveng »

Just try using ux with Google Artifact Registry and AWS CodeArtifact. You need the username in the URL with GAR and you need it in the environment variable with AWS. I'm not sure who's causing the pain with using uv with private repositories (but I'd bet it's uv), but they are selling a solution to that pain.

Full disclosure, uv rocks and is way better than poetry, setuptools and whatever complicated and non-zen way packaging python has had in the past.

Post reply on HN