6 ms·

Using virtualenv? Or venv? Or poetry? Or pyenv? Or pipenv? Or conda? Or something-else-I-can't-think-of-right-now? It's still a mess. Arguably, a worse

by __d 4y ago

Using virtualenv? Or venv? Or poetry? Or pyenv? Or pipenv? Or conda? Or something-else-I-can't-think-of-right-now? It's still a mess. Arguably, a worse mess than it used to be.

smnrchrds 4y ago
I use poetry and forget the rest of them exist. It has worked well so far.
- zackees 4y ago
  Poetry seems to be the most npm-style package management for python.
  - smnrchrds 4y ago
    I only have a passing knowledge of NPM, as I am not a JS dev, but I believe you are correct. Poetry has taken good ideas from other ecosystems and applied them to the Python world.
- dayjah 4y ago
  poetry is a game changer for sure. I’ve found using conda, in dev, to provide system libraries and poetry (+ a build.py for our C extensions) to be a really comfortable experience. In CI we use cibuildwheel to produce “statically-linked” wheel files. They’re not really statically linked, but they behave as though they are by bundling all dependent libraries into the wheel and doing some RPATH “magic” to look those kind up during runtime. I’d like to reduce the delta between dev and CI at some point, but it is stable rn so I’m inclined not to futz with it.
viraptor 4y ago
The first two are the same, the rest are effectively different abstractions over them. (apart from pyenv which is not for packages) The whole thing about choices in python packaging became more of a meme than reality. There are specific issues (pip itself not having a lock file equivalent), but they're often blown out of proportions.
bb88 4y ago
poetry and pipenv both use virtualenvs under the hood, wrapping it. They provide dep management. Pip/virtualenv never did dep management really. There was requirements.txt sure, but you had to manage that yourself.
agumonkey 4y ago
I had that convo few days ago. What surprises me is that pip venv were almost ok. But since there's twenty thousands new ways that popped all at once. And I can't understand which does what better.
rcarmo 4y ago
They all change PATH somehow. Which one you use depends on your use case. I, for instance, prefer pyenv for having a runtime and package set that covers most of my projects and virtualenvs for test sandboxes of new package versions. Conda, for instance, is great for ML and scientific given the extra niceties for replicating environments, but most specifically because you get package sets optimized for your analysis needs.

by __d 4y ago

Using virtualenv? Or venv? Or poetry? Or pyenv? Or pipenv? Or conda? Or something-else-I-can't-think-of-right-now? It's still a mess. Arguably, a worse mess than it used to be.

smnrchrds 4y ago

I use poetry and forget the rest of them exist. It has worked well so far.

zackees 4y ago
Poetry seems to be the most npm-style package management for python.
- smnrchrds 4y ago
  I only have a passing knowledge of NPM, as I am not a JS dev, but I believe you are correct. Poetry has taken good ideas from other ecosystems and applied them to the Python world.
dayjah 4y ago
poetry is a game changer for sure. I’ve found using conda, in dev, to provide system libraries and poetry (+ a build.py for our C extensions) to be a really comfortable experience. In CI we use cibuildwheel to produce “statically-linked” wheel files. They’re not really statically linked, but they behave as though they are by bundling all dependent libraries into the wheel and doing some RPATH “magic” to look those kind up during runtime. I’d like to reduce the delta between dev and CI at some point, but it is stable rn so I’m inclined not to futz with it.

viraptor 4y ago

The first two are the same, the rest are effectively different abstractions over them. (apart from pyenv which is not for packages) The whole thing about choices in python packaging became more of a meme than reality. There are specific issues (pip itself not having a lock file equivalent), but they're often blown out of proportions.

bb88 4y ago

poetry and pipenv both use virtualenvs under the hood, wrapping it. They provide dep management. Pip/virtualenv never did dep management really. There was requirements.txt sure, but you had to manage that yourself.

agumonkey 4y ago

I had that convo few days ago. What surprises me is that pip venv were almost ok. But since there's twenty thousands new ways that popped all at once. And I can't understand which does what better.

rcarmo 4y ago

They all change PATH somehow. Which one you use depends on your use case. I, for instance, prefer pyenv for having a runtime and package set that covers most of my projects and virtualenvs for test sandboxes of new package versions. Conda, for instance, is great for ML and scientific given the extra niceties for replicating environments, but most specifically because you get package sets optimized for your analysis needs.