461–470 of 479 posts
Is there a big enough commercial market for private Python package registries to support an entire company and its staff? Looks like they're hiring for $250k engineers, starting a $26k/year OSS fund, etc. Expenses seem a bit high if this is their first project unless they plan on being acquired?
What does GPU-aware mean in terms of a registry? Will `uv` inspect my local GPU spec and decide what the best set of packages would be to pull from Pyx? Since this is a private, paid-for registry aimed at corporate clients, will there be an option to expose those registries externally as a public instance, but paid for by the company? That is, can I as a vendor pay for a Pyx registry for my own set of packages, and t…
> Will `uv` inspect my local GPU spec and decide what the best set of packages would be to pull from Pyx? We actually support this basic idea today, even without pyx. You can run (e.g.) `uv pip install --torch-backend=auto torch` to automatically install a version of PyTorch based on your machine's GPU from the PyTorch index. pyx takes that idea and pushes it further. Instead of "just" supporting PyTorch, the registr…
Is the plan to also provide accurate (curated) metadata for security and compliance purposes?
Earlier quoted context omitted.
Man I used python sparingly over the years and I still had to deal with all those package manager changes. Worse than the JS bundling almost?
No, the JS bundling changes are almost monthly and it's impossible to know which one should I use and what will be broken because of my choice.
Earlier quoted context omitted.
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…
I believe that you are sincere and truthful in what you say. Unfortunately, the integrity of employees is no guard against the greed of investors. Maybe next year investors change the CEO and entire management and they start monetizing the open source tools. There is no way of knowing. But history tells us that there is a non-trivial chance of this happening.
Earlier quoted context omitted.
I love Nix as much as the next guy, but I also need my coworkers to be able to get things to work on their non-NixOS machines. Have you found an easy way to have Nix install packages through uv (from a pyproject.toml / uv.lock files)? Right now I just do programs.nix-ld.enable = true; and use uv completely separately from Nix.
uv2nix is great from my experience https://github.com/pyproject-nix/uv2nix
I do not trust Astral. Much ad language. They do not explain what an installation of their software does to my system. They use the word "platform".
It's hosted SaaS; you don't install it on your system.
[1] https://rwsdk.com/blog/saas-is-just-vendor-lock-in-with-bett...
Earlier quoted context omitted.
Well I started with pip because it's what I was told to use. But it was slow and had footguns. And then I started using virtualenv, but that only solved part of the problem. So I switched to conda, which sometimes worked but wrecked my shell profile and often leads to things mysteriously using the wrong version of a package. So someone told me to use pipenv, which was great until it was abandoned and picked up by som…
> But the dependency I need is built and packaged differently for different operating systems and flavor of GPU, and now my coworkers can't get the project to install on their laptops. This is why containers are great IMO. It's meant to solve the problem of "well it works on my machine"
Earlier quoted context omitted.
Given that WSL is pretty much just Linux, I don't see what relevance Visual Studio compiler versions have to it. WSL binaries are always built using Linux toolchains. At the same time, even on Windows, libc has been stable since Win10 - that's 10 years now. Which is to say, any binary compiled by VC++ 2015 or later is C-ABI-compatible with any other such binary. The only reasons why someone might need a specific comp…
If you have to use, e.g., CUDA Toolkit 11.8, then you need a specific version of VS and its build tools for CUDA's VS integration to work. I don't know why exactly that is and I wish I didn't have to deal with it.
Earlier quoted context omitted.
Anaconda solved the same problem ~10+ years ago already.
HAHAHAH don't even get me started on how bad anaconda is. On how slow the installer + interpreter, how they avoided being a part of the usual pip workflow, bloated environment, cross platform inconsistencies, extremely slow dependency resolution, etc etc etc...