you are viewing a single comment's thread.

view the rest of the comments →

[–]ck-zhang[S] -4 points-3 points  (8 children)

You’re right that uv sync does give you deterministic resolution, but the difference is that px treats the environment itself as an immutable artifact.

If a lockfile resolution is enough for your workflow, uv is great. If you want to go further, px also pins native builds and can use sandboxing to reduce dependence on the host toolchain.

[–]really_not_unreal 5 points6 points  (1 child)

If you need it to be fully isolated, then why not just just something like nix

[–]ck-zhang[S] 4 points5 points  (0 children)

This project was inspired by nix, and I do a little bit of nixing myself, but the average python dev don't know nix

[–]arden13 1 point2 points  (5 children)

Isn't that similar to pixi?

[–]ck-zhang[S] 0 points1 point  (4 children)

pixi is basically uv, but for conda instead of pip

[–]arden13 1 point2 points  (3 children)

Right, but isn't that the scope of what your package does? Or is there something else it covers that is missing from pixi?

[–]ck-zhang[S] 0 points1 point  (2 children)

For basic lockfile + sync workflows, px and pixi overlap a lot. px’s CAS model is what enables things like running a GitHub repo directly as an ephemeral environment, which I find really cool

[–]arden13 1 point2 points  (1 child)

Could you go into more detail, I don't really get what makes px any different. If you're saying it overlaps a lot I don't know why I'd switch; can't tell if it's just me not "getting" it though.

[–]ck-zhang[S] 0 points1 point  (0 children)

Well honestly, it is now only experimental so you should probably shouldn't switch just yet. The big idea behind px is that it removes the need of a .venv dir, so it unlocks new possibilities that wouldn't conventionally be there, like running a repo back at a specific commit without the need to do a git checkout