I recently started using https://github.com/prefix-dev/pixi for Python projects. I really love it so far, but this tool looks a bit more mature, which makes sense considering pixi is relatively new.
Why is it based on the Conda ecosystem? Do you happen to know?
I assume it's for portability, but that sounds heavy.
My org does a lot of work combining machine learning with oceanographic and climate modeling, which are both domains that have deep dependency chains that don't always mesh well, especially as our researchers mix in R and other languages as the same time, and the Conda ecosystem helps us a ton with that, but there are issues that `conda` and `mamba` don't help us out with.
Pixi takes a swing at some of what the Conda ecosystem hasn't been great at (at least without a lot of manual custom ceremony) that Cargo, Poetry, Pipenv, PDM, and other dependency and workflow management tools have demonstrated can be done such as lock files, cross platform dependency management, task running, and defining multiple related environments.
What's really cool when you have a mix of projects, Pixi can work almost entirely PyPI native out of a `pyproject.toml`, other than installing Python from Conda-Forge, so you can mix and match environments but stay with the same tool. https://prefix.dev/blog/using_python_projects_with_pixi docs: https://pixi.sh/latest/advanced/pyproject_toml/
asdf handles tools, not really packages. So asdf would install Python and not Python packages.
asdf.vm together with pipenv is my go-to for Python environment management.
[0] https://pip-tools.readthedocs.io/en/stable/
As for Poetry, it is constantly improving and has gotten very popular. It should not be dismissed, especially for larger projects since its dependency management is so much better than pipenv. This is a good primer: https://diegoquintanav.github.io/poetry-primer.html
I think it’s fair to see appeal in poetry, but ultimately the maintainers have created a culture that feels a bit too non-collaborative to outside ideas or use cases beyond what they more narrowly envisage. That said, my perspective may just be tainted by multiple poor experiences interacting with the maintainers.
then you'd also need rbenv, nvm, etc.
and pyenv can implode in marvelous ways.
pyenv isn’t perfect, and isn’t what I’d use for prod images, but for dev setup it’s relatively bulletproof and less issue-prone than any alternative I’ve seen.
The other 2 reasons are more subjective. The first being I've had less issues installing packages with PDM. It's been a while and I don't remember which specific packages Poetry struggled to install, but my takeaway was just that I don't run into those problems with PDM the way I did with Poetry.
The other larger/more consequential reason is the maintainers of Poetry. There have been a number of GitHub issues replies laying out plans for things they will/won't do with Poetry, and it didn't inspire confidence in me. I want to do things the "Python way," not the "Poetry way," and PDM adheres more closely to the direction the Python project is moving. I don't want surprises later down the road when a tool (Poetry) is doing a bunch of custom stuff that eventually may not be compatible with the ecosystem at large.
All that being said, I had a lot of good things to say about Poetry while I was using it, and I do understand why people make it their package/project manager. Just wasn't the right fit for me.