[sabellito]

Every time I see these things, they look cool as hell, I get excited, then I try to get them working on my gaming PC (that has the GPU), I spend 1-2h fighting with python and give up.

Today's issue is that my python version is 3.12 instead of <3.12,>=3.9. Installing python 3.11 from the official website does nothing, I give up. It's a shame that the amazing work done by people like the OP gets underused because of this mess outside of their control.

"Just use docker". Have you tried using docker on windows? There's a reason I never do dev work on windows.

I spent most of my career in the JVM and Node, and despite the issues, never had to deal with this level of lack of compatibility.

[mrinterweb]

Meta comment about this thread: there is a lot of just use "x", use "y", use "z", use ... comments. Kind of proves the point of the top level comment.

I feel the same way when installing some python library. There's a bunch of ways to manage dependencies that I wish was more standardized.

[jhoho]

Let me introduce you to the beautiful world of virtual environments. They save you the headache of getting a full installation to run, especially when using Windows.

I prefer miniconda, but venv also does the job.

[turnsout]

And this works about 25% of the time. The rest of the time, there is some inscrutable error with the version number of a dependency in requirements.txt or something similar, which you end up Googling, only to find an open issue on a different project's Github repo.

Someone needs to make an LLM agent that just handles Python dependency hell.

[releaslot]

"Someone needs to make an LLM agent that just handles Python dependency hell."

This is why they are constantly delaying GPT 5.

[turnsout]

Haha fair enough—if they can solve the Python situation, I'd be fine slapping the "AGI" label on it.

[mckeed]

As someone who doesn't develop in python but occasionally tries to run python projects, it's pretty annoying to have to look up how to use venv every time.

I finally added two scripts to my path for `python` and `pip` that automatically create and activate a virtual env at `./.venv` if there isn't one active already. It would be nice if something like that was just built into pip so there could be a single command to run like Ruby has now with Bundler.

[krferriter]

`uv` is great for this because its super fast, works well as a globally installed tool (similar to conda), and can also download and manage multiple versions of python for you, and which version is used by which virtualenvironment.

[Grimblewald]

While my uv use is still early days, i would second this recommendation. I've found it to have the functionallity i miss from conda in venv, but faster and more reliable than conda.

[s5ma6n]

I am also using conda and specifically mamba which has a really quick dependency solver.

However, sometimes repos require system level packages as well. Tried to run TRELLIS recently and gave up after 2h of tinkering around to get it to work in Windows.

Also, whenever I try to run some new repo locally, creating a new virtual environment takes a ton of disk space due to CUDA and PyTorch libraries. It adds up quickly to 100s of gigs since most projects use different versions of these libraries.

</rant> Sorry for the rant, can't help myself when it's Python package management...

[WanderPanda]

Same experience. They should really store these blobs centrally under a hash and link to them from the venvs

[regularfry]

Virtual environments with venv don't answer the python version problem unless you throw another tool into the mix.

[laborcontract]

uv solves this problem.

  uv venv python3.11

done.

[krferriter]

conda and uv do manage python versions for you which is part of their appeal, especially on systems that don't make it super straightforward to install multiple different versions of pre-compiled runtimes because their official OS channel of installing python only offers one version. At least on macos, brew supports a number of recent versions that can be installed simultaneously.

[underdeserver]

Hmm? My venvs do include the Python version (via symlink to /bin). Don't yours?

[diggan]

If you use something like uv (expanded here: https://news.ycombinator.com/item?id=43904078), I think it does. But if you just do `python -m venv .venv`, you get the specific version you used to create the virtual environment with. Some OSes seem to distribute binaries like `python3.8`, `python3.9` and so on so you could do `python3.8 -m venv .venv` to look one env to a specific version, but a bit of a hassle.

[regularfry]

The GP's problem was (apparently) an inability to install the right python version, not an inability to select it.

[homeless_engi]

Conda does! `conda create -n myenv python=3.9`, for example

[atoav]

uv is the way.

https://docs.astral.sh/uv/

Sadly it appears that people in the LLM space aren't really all that good at packaging their software (maybe, on purpose).

[diggan]

> Sadly it appears that people in the LLM space

This seems to be somewhat of a Python side-effect, same goes for almost any Python projects thrown together by people who hasn't spent 10% of their life fighting dependency management in Python.

But agree with uv being the best way. I'm not a "real" Python programmer, similar boat to parent that I just end up running a bunch of Python projects for various ML things, and also create some smaller projects myself. Tried conda, micromamba, uv, and a bunch of stuff in-between, most of them breaks at one point or another, meanwhile uv gives me the two most important things in one neat package: Flexible Python versions depending on project, and easy management of venv's.

So for people who haven't given it a try yet, do! It does make using Python a lot easier when it comes to dependencies. These are the commands I tend to use according to my history, maybe it's useful as a sort of quickstart. I started using uv maybe 6 months, and this is a summary of literally everything I've used it for so far.

    # create new venv in working directory with pip + specific python version
    uv venv --seed --python=3.10
    # activate the venv
    source .venv/bin/activate
    # on-the-fly install pip dependencies
    uv pip install transformers
    # write currently installed deps to file
    uv pip freeze > requirements.txt
    # Later...
    # install deps from file
    uv pip install -r requirements.txt
    # run arbitrary file with venv in path etc
    uv run my_app.py
    # install a "tool" (like global CLIs) with a specific python version, and optional dependency version
    uv tool install --force --python python3.12 aider-chat@latest

[bb88]

There's been a movement away from requirements.txt towards pyproject.toml. And commands like "uv add" and "uv install" take most of the pain of initializing and maintaining those dependencies.

[diggan]

Thanks, as mentioned, I'm not really a Python programmer so don't follow along the trends...

I tried to figure out why anyone would use pyproject.toml over requirements.txt, granted they're just installing typical dependencies and didn't come up with any good answer. Personally I haven't had any issues with requirements.txt, so not sure what pyproject.toml would solve. I guess I'll change when/if I hit some bump in the road.

[atoav]

There are some advantages to pyproject.toml

1. You can differenciate between different dependency groups like build dependencies, dev dependencies, test dependencies and regular dependencies. So if someone uses some dependency only in dev previously you either had to install that manually or your requirements.txt installed it for you without you needing it.

2. It adds a common description for project metadata that can be used

3. Adds a place where tool settings like those of a linter or a formatter can be stored (e.g. ruff and black)

4. Its format is standardized and allows it to be integrated with multiple build tools, toml is a bit more standardized than whatever custom file syntax python used before

[bb88]

virtualenvs are great, but they're not great on their own. requirements.txt work sorta, but then any package with more than 50 requirements requires a non-trivial amount of manual labor to maintain. (Hell even 20 deps are a pain)

Astral uv and poetry both maintain the pyproject.toml for you -- and as a bonus, they maintain the virtualenv underneath.

Then for the complete python newbs, they can run 'uv sync' or 'poetry install' and they don't have to understand what a virtualenv is -- and they don't need root, and they don't have to worry about conflicts, or which virtualenv is which, etc.

So the simple case:

    mkdir test
    cd test

    # init a new project with python 3.13
    uv init -p 3.13

    # Add project deps
    uv add numpy
    uv add ...

    # Delete the venv
    rm -rf .venv

    # reinstall everything (with the exact versions)
    uv sync

    # Install a test package in your venv
    uv pip install poetry

    # force the virtualenv back into a sane state (removing poetry and all it's deps)
    uv sync

    # update all deps
    rm uv.lock
    uv lock

Now cat your pyproject.toml, and you'll see something like this:

    [project]
    name = "test"
    version = "0.1.0"
    description = "Add your description here"
    readme = "README.md"
    requires-python = ">=3.13"
    dependencies = [
        "numpy>=2.2.5",
        "pillow>=11.2.1",
        "scipy>=1.15.2",
    ]

[whacked_new]

does uv play well with cuda?

I use nix-shell when possible to specify my entire dev environment (including gnumake, gcc, down to utils like jq)

it often doesn't play well with venv and cuda, which I get. I've succeeded in locking a cuda env with a nix flake exactly once, then it broke, and I gave up and went back to venv.

over the years I've used pip, pyenv, pip env, poetry, conda, mamba, younameit. there are always weird edge cases especially with publication codes that publish some intersection of a requirements.txt, pyproject.toml, a conda env, to nothing at all. There are always bizarro edge cases that make you forget if you're using python or node /snark

I'll be happy to use the final tool to rule them all but that's how they were all branded (even nix; and i know poetry2nix is not the way)

[diggan]

I generally use nix-shell whenever I can too, only resorting to `uv` for projects where I cannot expect others to neccessarly understand Nix enough to handle the nix-shell stuff, even if it's trivial for me.

AFAIK, it works as well with cuda as any other similar tool. I personally haven't had any issues, most recently last week I was working on a transformer model for categorizing video files and it's all managed with uv and pytorch installed into the venv as normal.

[bb88]

UV uses venv underneath.

[amelius]

For security maybe you should do all of this inside a sandbox.

[diggan]

I'm assuming most people run untrusted stuff like 3rd party libraries in some sort of isolated environment, unless they're begging to be hacked. Some basic security understanding has to be assumed, otherwise we have a long list to go through :)

[amelius]

Ok, but getting your GPU to work inside a sandbox can be a difficult step too. I bet most people give up and just run the commands without a sandbox.

Therefore, maybe it is a good idea to include those instructions.

[scld]

Probably because they're just prompting "Please package this software" and shipping it if it works once.

[ijustlovemath]

I've had a lot of success using podman with pyenv for python versions, and plain old venv for the actual environment. All of this lives within WSL, but you can still access everything locally with localhost://

If you just want to use windows, pyenv-win exists and works pretty well; just set a local version, then instantiate your venv.

uv does certainly feel like the future, but I have no interest in participating in a future VC rugpull.

[koljab]

Yes, you're absolutely right. I'll provide UV and conda support soon, especially for Windows. I'm using python 3.10 still, maybe that's the issue. You can always mail me your current problem or log an issue, I really care about opening up the repo for as many ppl to use as possible.

[marziply]

Don't use Bindows then? The tech industry is largely focused on Unix systems so of course there will be inevitable sharp edges when you work on a garbage system like Bindows...

[zo1]

Do you know how much time I (or any other dev) would spend getting a C#, or C++, or JS/TS, or Java or any language project running that has anything to do with ML up and running on tech and tooling we are kinda unfamiliar with? Yes, pretty much 1-2 hours, and very likely more.

Sorry but this sort of criticism is so contrived and low-effort. "Oh I tried compiling a language I don't know, using tooling I never use, using an OS I never use (and I hate too btw), and have no experience in any of it, oh and on a brand-new project that's kinda cutting-edge and doing something experimental with an AI/ML model."

I could copy-paste your entire thing, replace Windows with Mac, complain about homebrew that I have no idea how to use, developing an iMac app using SwiftUI in some rando editor (probably VSCode or VI), and it would still be the case. It says 0 about the ecosystem, 0 about the OS, 0 about the tools you use, 0 about you as a developer, and dare I say >0 about the usefulness of the comment.

[zamadatix]

For development is one thing, the problem is with this being how the LLM app distribution for general use works too.

[TeamDman]

Python dependency management sucks ass. Installing pytorch with cuda enabled while dealing with issues from the pytorch index having a linux-only version of a package causing shit to fail is endlessly frustrating

A good ecosystem has lockfiles by default, python does not.

[reginald78]

I spin up a whole linux VM with a passed through nvidia GPU for these and I still spend the majority of the time fighting the python and figuring out the missing steps in the setup instructions.

Glad for this thread though since it looks like there's some tricks I haven't tried, plus since it seems a lot of other people have similar issues I feel less dumb.

[bobbylarrybobby]

UV is the one final solution to Python problems. Install globally, then you're good to go.

[ericmcer]

it isn't that hard, but also fiddling with python versions is something I don't mind sinking 2 hours into at work but can't tolerate doing for 10 minutes with my free time.

[whatevaa]

Python packages and Windows don't mix well