What is Pixi exactly? Is it a wrapper around Conda? Does it a completely different package manager that leverages the packages available on Conda channels?
Work in dedicated, isolated environments that can still be recreated in a 100 years.
I don’t think it’s too hard to believe that it’s possible. I can run an emulator for an IBM 1620 on my laptop and run FORTRAN II programs on it. The more pertinent question is whether I would want this. Something that lets me create a snapshot that doesn’t change is easy. Something that lets me easily apply security updates from my dependencies is hard.
It is a re-write of the conda tooling (plus some) in Rust, leveraging (existing) Conda channels and package specifications, if my understanding is right. Pixi is just one part of it, there is also rattler (the underlying Rust library) along with rattler-built (to build conda packages), a hosted service (prefix.dev) and probably some other bits and pieces that are or will be developed in the future. Some (or probably most) of this is still under heavy development, so its early days.
Would the effort put into creating this, and the future effort to be put into its “ambitious plans”, have been or be better spent improving the functionality and user-friendliness of the next best option that already existed?
I’m reminded of a line from the MPD client developer documentation:
Before you develop a new client, consider joining an existing client project. There are many clients, but few are mature; we need fewer, but better clients.
I’m a bit confused why one of the examples suggest installing pipx or condax globally… wouldn’t you just install tools with pixi directly instead of pipx or condax?
That’s the whole problem with pixi and all the equivalent projects. The people that need them the most are the ones that are the least likely to understand how to use them correctly.
I’m pretty sure pixi will cause as many problems as it solves.
He I work at prefix, where did you get the feeling that we suggest using pipx or condax because that is not our intention. pixi global install PACKAGE installs a package that will then be globally accessible, like how pipx and condax works.
on a second reading, i can see this is saying “globally install tools in a manner similar to pipx or condax”, not “globally install tools such as pipx or condax”
I’ve been using pixi for a while now, and to me its value doesn’t (only) lie in helping with Python project development, but making it easy to create environments for everything Conda provides packages for (limiting that to only Python related stuff feels a bit short-sighted to me).
I use it to quickly create environments that I can use a bit like Docker images, without the Docker/Podman overhead, and most importantly, without needing root to create anything. How you integrate those environments into your workflow is up to you, but it really shines (atm) with Project based workflows.
Imagine you have a Python backend you want to collaborate on with a frontend dev, and the frontend dev has no idea how to setup Python virtualenvs. With pixi, you only share the pixi config in the project folder, your colleague downloads the pixi binary, runs any of the pixi run your-backend-start-commands you prepared and can start developing against your REST API in its latest (git) version. You could also forward the ’pixi run ’ to npm, to make it even more seamless for JS devs.
Of course there are other ways to do this, but none I know is as seamless as this. And that’s just one example, your usecases are not really limited to Python, but of course Python is very well integrated.
I’ve also used it successfully to install ansible on a machine and use pixi commands to quickly run ansible roles etc. Again, nothing you couldn’t do in some other ways, but pixi makes it very quick and easy.
Against some other commenters sentiments, this is a wheel I don’t mind being reinvented and made rounder, it feels to me that the decision to re-write a lot of the tooling around conda from the ground up really pays off here. The team already did a lot of good work with (C-based) micromamba, so I for one trust their judgement when they think they the need to start over.
pip is the default package installer that comes with Python.
poetry is a third-party package manager and package build tool with some workflow and workspace-management tools.
conda is a third-party package installer with a focus on the scientific/numeric community and on the broader ecosystem of not-just-Python tools and dependencies that community relies on.
Yeah, fair enough, I was pondering whether I should include it when I posted this, but decided against it in the end because to me it felt pixi/conda are useful in a much wider context.
What is Pixi exactly? Is it a wrapper around Conda? Does it a completely different package manager that leverages the packages available on Conda channels?
How does Pixi do this? I want to believe.
I’m not even sure that we’ll still have the same CPU architectures in 100 years, so I’m skeptical.
I don’t think it’s too hard to believe that it’s possible. I can run an emulator for an IBM 1620 on my laptop and run FORTRAN II programs on it. The more pertinent question is whether I would want this. Something that lets me create a snapshot that doesn’t change is easy. Something that lets me easily apply security updates from my dependencies is hard.
That’s using a VM. The claim on the Pixi website is that it is being done without even using containers.
It is a re-write of the conda tooling (plus some) in Rust, leveraging (existing) Conda channels and package specifications, if my understanding is right. Pixi is just one part of it, there is also rattler (the underlying Rust library) along with rattler-built (to build conda packages), a hosted service (prefix.dev) and probably some other bits and pieces that are or will be developed in the future. Some (or probably most) of this is still under heavy development, so its early days.
Would the effort put into creating this, and the future effort to be put into its “ambitious plans”, have been or be better spent improving the functionality and user-friendliness of the next best option that already existed?
I’m reminded of a line from the MPD client developer documentation:
I’m a bit confused why one of the examples suggest installing pipx or condax globally… wouldn’t you just install tools with pixi directly instead of pipx or condax?
That’s the whole problem with pixi and all the equivalent projects. The people that need them the most are the ones that are the least likely to understand how to use them correctly.
I’m pretty sure pixi will cause as many problems as it solves.
I’m probably borderline spamming at this point, but better post a link again than explain the whole thing in a comment repeatedly: https://www.bitecode.dev/p/why-not-tell-people-to-simply-use
He I work at prefix, where did you get the feeling that we suggest using
pipxorcondaxbecause that is not our intention.pixi global install PACKAGEinstalls a package that will then be globally accessible, like howpipxandcondaxworks.from the article:
on a second reading, i can see this is saying “globally install tools in a manner similar to pipx or condax”, not “globally install tools such as pipx or condax”
This needs to be rewritten to be less ambiguous.
I’ve been using pixi for a while now, and to me its value doesn’t (only) lie in helping with Python project development, but making it easy to create environments for everything Conda provides packages for (limiting that to only Python related stuff feels a bit short-sighted to me).
I use it to quickly create environments that I can use a bit like Docker images, without the Docker/Podman overhead, and most importantly, without needing root to create anything. How you integrate those environments into your workflow is up to you, but it really shines (atm) with Project based workflows.
Imagine you have a Python backend you want to collaborate on with a frontend dev, and the frontend dev has no idea how to setup Python virtualenvs. With pixi, you only share the pixi config in the project folder, your colleague downloads the pixi binary, runs any of the
pixi run your-backend-start-commandsyou prepared and can start developing against your REST API in its latest (git) version. You could also forward the ’pixi run ’ to npm, to make it even more seamless for JS devs.Of course there are other ways to do this, but none I know is as seamless as this. And that’s just one example, your usecases are not really limited to Python, but of course Python is very well integrated.
I’ve also used it successfully to install ansible on a machine and use pixi commands to quickly run ansible roles etc. Again, nothing you couldn’t do in some other ways, but pixi makes it very quick and easy.
Against some other commenters sentiments, this is a wheel I don’t mind being reinvented and made rounder, it feels to me that the decision to re-write a lot of the tooling around conda from the ground up really pays off here. The team already did a lot of good work with (C-based) micromamba, so I for one trust their judgement when they think they the need to start over.
I’m not a Python dev - what’s the difference between “conda” and “pip” or “poetry”? I’ve only used pip/poetry
pipis the default package installer that comes with Python.poetryis a third-party package manager and package build tool with some workflow and workspace-management tools.condais a third-party package installer with a focus on the scientific/numeric community and on the broader ecosystem of not-just-Python tools and dependencies that community relies on.Also, conda is tied to anaconda, which is a commercial product, albeit with a free ofter.
But I would advice using anything else than pip if you have to ask this question.
See: https://www.bitecode.dev/p/relieving-your-python-packaging-pain and https://www.bitecode.dev/p/why-not-tell-people-to-simply-use
I’ve suggested
pythontag to go with thisYeah, fair enough, I was pondering whether I should include it when I posted this, but decided against it in the end because to me it felt pixi/conda are useful in a much wider context.