top | item 43347777

(no title)

rullopat | 11 months ago

[flagged]

discuss

order

mrlatinos|11 months ago

Please, it's every 4 years.

affinepplan|11 months ago

uv is worth changing to. it legitimately solves python packaging problems the way no other proposed solution thus far could.

fwip|11 months ago

I think you might have your dates confused. Pyenv was first released about 8 years ago.

alexjplant|11 months ago

You're being downvoted (for snark presumably) but you have a point.

During my tenures as a Python developer I've had to deal with pip, pipx, venv, pipenv, setuptools, conda, and poetry. I'd not heard of pyenv or uv until this thread (or maybe I've touched pyenv and got it confused with one of the 7 other tools I mentioned) and I'm sure there are other dependency/environment management tools floating around that I missed.

Now that I'm back to Go it's `go get` with some mise tasks. It's a serious breath of fresh air. The Python ecosystem probably won't ever catch up to npm when it comes to cranking out shiny new things but it's definitely more bleeding edge than a lot of other languages.

turtlebits|11 months ago

In the past 10 years, virtualenv and pip have been perfectly fine for me. They still are. I ignored any new tooling.

uv is great so far, I did run into a hiccup where moving from pip with a requirements.txt file to uv slowed a CI pipeline way down that I had to revert.

zahlman|11 months ago

> I'd not heard of pyenv or uv until this thread (or maybe I've touched pyenv and got it confused with one of the 7 other tools I mentioned)

I must have seen at least a dozen threads here about uv since joining half a year ago. But maybe that's because I actively look for Python discussion (and I'm probably just generally more active here).

I wish I'd paid more attention a few years ago and thought about the packaging problem more intensely - in an alternate universe I might have released Paper before uv came out, but I didn't even really start considering these issues until mid-2023 (and of course I've had plenty of other things to distract me since then).

For what it's worth, my general thesis is that most of the problems really boil down to Pip being what it is, and a lot of the rest boil down to Setuptools being what it is.

JimDabell|11 months ago

> Why in the Python ecosystem you change package manager every 2 week?!?

setuptools (2006), pip (2008), venv (2011), conda (2012), pipx (2017), pipenv (2017), poetry (2018)

They don’t have a point. You listed seven tools – most of which aren’t package managers at all – which were created over the course of twelve years. That’s not even remotely like changing package manager every two weeks. That goes far beyond hyperbole, straight into misrepresentation.

rat87|11 months ago

The reason there have been so many is because the standard included tools (pip, venv) are not great. And others could still use improvements.

Venv and setup tools aren't really package managers. Pipx is only meant for installing Dev tools per user (in isolated Venvs).

pyenv does something a bit different from those tools you listed(maybe it'd part of cones I haven't tried it). Its not a dependency manager its a python version manager like nvm (node version manager). It helps you manage downloading and compiling python from source and it let's you specify python version in a .python-version file and provides a shim to find the right python for a project(compiling it if its not already available).

I tried pipenv and despite being hyped for it, it had a lot of issues. Then I tried poetry which seemed much better but was still sort of slow and got stuck updating lock files sometimes.

I haven't even tried pdm. Or various conda package managers since its mainly used by scientists with lots of binary dependency needs.

Then ~~uv~~ rye came along and seemed to fix things. It replaced pip+pip tools/pipenv/poetry. Also replaced pipx(install python tools in isolated venvs then add it to users ./local/bin). Also replaced pyenv but instead of compiling python which takes a while and can be troublesome it downloads portable builds https://astral.sh/blog/python-build-standalone (which do have some downsides/compatibility issues but are usually better then compiling python). It was also written in rust so avoided circular venv issues that sometimes come with installing python packages since it had a self contained binary(plus some shims).

Then UV came along, the projects merged and most development is happening in uv. Despite the rye-> switch most things are pretty similar and I feel a lot of excitement towards it. The one big difference is there's no shims to automatically call the right python for a project from UV. Instead you need to run uv run script.py

Astral the guys behind UV took over the independent python builds and have also built the most popular python formater/linter these days - ruff (also written in rust, also fast they're also looking into adding a better type checker for python type hints).

I'd reccomend trying it for your next project I think it could become the defacto packaging/version tool for python