451–460 of 1001 posts
Earlier quoted context omitted.
There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.
You aren’t kidding. Especially if it’s some bioinformatics software that is just hanging out there on GitHub older than a year…
Earlier quoted context omitted.
So many times I have come onto a library or tool that would fix my problem, and then realized “oh crap, it’s in Python, I don’t want to spend few hours building a brittle environment for it only for that env to break next time I need to use it” - and went to look for a worse solution in better language.
I really don't get this. I can count on no hands the number of times I've had problems simply going "pip install cool-thing-i-found". Sure, this is just my experience, but I use Python a lot and use a lot of tools written in Python.
Earlier quoted context omitted.
Installing an out-of-distro deb/rpm/msi/dmg/etc package is just as unsafe as curl|sh. Or even unsafer, as packages tend to require root/admin.
A package is at least a signable, checksummable artefact. The curl | sh thing could have been anything and after running it you have no record of what it was you did. There have also been PoCs on serving malicious content only when piped to sh rather than saved to file. If you want to execute shell code from the internet, at the very least store it in a file first and store that file somewhere persistent before execu…
I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing
There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.
Earlier quoted context omitted.
There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.
Same! And Python was my first, and is currently my second-highest-skill language. If someone's software's installation involves Python, I move on without trying. It used to be that it would require a Python 2 interpreter. Honorable mention: Compiling someone else's C code. Come on; C compiles to a binary; don't make the user compile.
I'm assuming a Linux based system here, but consider the case where you have external dependencies. If you don't want to require that the user installs those, then you gotta bundle then or link them statically, which is its own can of worms.
Not to mention that a user with an older glibc may not be able to run your executable, even if they have your dependencies installed. Which you can, for example, solve by building against musl or a similar glibc alternative. But in the case of musl, the cost is a significant overhead if your program does a lot of allocations, due to it lacking many of the optimizations found in glibc's malloc. Mitigating that is yet another can of worms.
There's a reason why tools like Snap, AppImage, Docker, and many more exist, each of which are their own can of worms
Can someone steelman the python tooling ecosystem for me? Having a new packaging / dependency manager every few years seems excessive.
uv is finally an all-in-one tool that finally takes all of the good ideas from previous projects and combines them together to work well as one (and unbelievably fast). The fact that it's a binary, not written in python, also simplifies bootstrapping. So you don't need python+dependencies installed in order to install your python+dependencies.
I'm surprised by how much I prefer prepending "uv" to everything instead of activating environments - which is still naturally an option if that's what floats your boat. I also like how you can manage Python versions very easily with it. Everything feels very "batteries-included" and yet local to the project. I still haven't used it long enough to tell whether it avoids the inevitable bi-yearly "debug a Python enviro…
> how much I prefer prepending "uv" to everything instead of activating environments You can also prepend the path to the virtual environment's bin/ (or Scripts/ on Windows). Literally all that "activating an environment" does is to manipulate a few environment variables. Generally, it puts the aforementioned directory on the path, sets $VIRTUAL_ENV to the venv root, configures the prompt (on my system that means mod…
Earlier quoted context omitted.
So many times I have come onto a library or tool that would fix my problem, and then realized “oh crap, it’s in Python, I don’t want to spend few hours building a brittle environment for it only for that env to break next time I need to use it” - and went to look for a worse solution in better language.
I really don't get this. I can count on no hands the number of times I've had problems simply going "pip install cool-thing-i-found". Sure, this is just my experience, but I use Python a lot and use a lot of tools written in Python.
God, I hate Python. Why is it so hard to not break code?
I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing
I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.
I hadn't paid any attention to rust before uv, but since starting to use uv, I've switched a lot of my performance-sensitive code dev to rust (with interfaces to python). These sorts of improvements really do improve my quality of life significantly. My hope is that conda goes away completely. I run an ML cluster and we have multi-gigabyte conda directories and researchers who can't reproduce anything because just to…
Have you figured out a good way to manage CUDA dependencies with uv?
does that fit the bill?