Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switching from Pyenv to Uv

bluesock.org

Post reply on HN
Print view View original

201–210 of 239 posts

Re: Switching from Pyenv to Uv

#201

Post by fluidcruft »

0xcoffee wrote: post #104
fluidcruft wrote: post #80

Earlier quoted context omitted.

I generally agree but one thing I find very frustrating (i.e. have not figured out yet) is how deal with extras well, particularly with pytorch. Some of my machines have GPU, some don't and things like "uv add" end up uninstalling everything and installing the opposite forcing a resync with the appropriate --extra tag. The examples in the docs do things like CPU on windows and GPU on Linux but all my boxes are linux.…

Does this help? https://github.com/astral-sh/uv/pull/7851

I haven't tried it yet but that looks like exactly what I've been missing.

Re: Switching from Pyenv to Uv

#202

Post by __MatrixMan__ »

Kwpolska wrote: post #120
__MatrixMan__ wrote: post #76

Earlier quoted context omitted.

We fork it. Whatever carrot the VC's dangle can be chased by the handful who care, and the rest of us can continue using the important part.

Ah, so that's why it's written in Rust. Less people who care about Python packaging are capable of forking it.

I guess this is a joke but honestly I think that Python -> Rust is a pretty strong one.

I'd bet that the sort of person who is maintaining packaging for a bunch of Python users would like an opportunity to learn Rust on the job. I would.

Re: Switching from Pyenv to Uv

#203

Post by DrBenCarson »

fluidcruft wrote: post #200
DrBenCarson wrote: post #107

Earlier quoted context omitted.

It sounds like you’re just looking for dependency groups? uv supports adding custom groups (and comes with syntactic sugar for a development group

It is... but basically it need to remember which groups are sync'd. For example if you use an extra, you have to keep track of it constantly because sync thrashes around between states all the time unless you play close and tedious attention. At least I haven't figured out how to make it remember which extras are "active". uv sync --extra gpu uv add matplotlib # the sync this runs undoes the --extra gpu uv sync # oop…

To make the change in your environment:

1. Create or edit the UV configuration file in one of these locations:

- `~/.config/uv/config.toml` (Linux/macOS)

- `%APPDATA%\uv\config.toml` (Windows)

2. Add a section for default groups to sync:

```toml

[sync]

include-groups = ["dev", "test", "docs"] # Replace with your desired group names

```

Alternatively, you can do something similar in pyproject.toml if you want to apply this to the repo:

```toml

[tool.uv]

sync.include-groups = ["dev", "test", "docs"] # Replace with your desired group names

```

Re: Switching from Pyenv to Uv

#205

Post by IshKebab »

Hackbraten wrote: post #197
IshKebab wrote: post #181

Earlier quoted context omitted.

Maybe, but even if that is the case it's sooooo much better that even the worst case (fork when they try to monetise it) is way better than any alternatives.

> fork when they try to monetise it To maintain a successful fork, not only are you going to need to find people who volunteer for maintaining a fork at that scale (including a large user base due to popularity), you’ll need to find skilled Rust developers, too. That’s going to be immensely difficult.

I mean, maybe. But I'd still much rather take that risk than flagellate myself with Pip or Pyenv or Poetry.

Re: Switching from Pyenv to Uv

#206

Post by insane_dreamer »

serjester wrote: post #194
insane_dreamer wrote: post #191

Earlier quoted context omitted.

uv is great and we’re switching over from conda for some projects. The resolver is lightning fast and the toml support is good. Having said that, there are 2 areas where we still need conda: - uv doesn’t handle non-python wheels, so if you need to use something like mkl, no luck - uv assumes that you want to use one env per project. However with complex projects you may need to use a different env with different bran…

You may want to checkout uv’s workspaces - they’re very handy for large mono repos.

Thanks. I looked at that but I believe it solves a different problem.

Re: Switching from Pyenv to Uv

#207

Post by eikenberry »

__MatrixMan__ wrote: post #202
Kwpolska wrote: post #120

Earlier quoted context omitted.

Ah, so that's why it's written in Rust. Less people who care about Python packaging are capable of forking it.

I guess this is a joke but honestly I think that Python -> Rust is a pretty strong one. I'd bet that the sort of person who is maintaining packaging for a bunch of Python users would like an opportunity to learn Rust on the job. I would.

IMO this is unlikely. Rust and Python have very little in common.

Re: Switching from Pyenv to Uv

#208

Post by theogravity »

BiteCode_dev wrote: post #132
theogravity wrote: post #70

Earlier quoted context omitted.

Thanks for the info. I looked at the group documentation, but it's not clear to me why I would want to use it, or where I would use it: https://docs.astral.sh/uv/concepts/projects/layout/#default-... (I'm a JS dev who has to write a set of python packages in a monorepo.)

sync is something you would rarely use, it's most useful for scripting. uv run is the bread and meat of uv, it will run any command you need in the project, and ensure it will work by synching all deps and making sure your command can import stuff and call python. In fact, if you run a python script, you should do uv run python the_script.py, It's so common uv run the_script.py will work as a shortcut. I will write a…

Did you mean group and not sync?

Really looking forward to the articles!

Re: Switching from Pyenv to Uv

#209

Post by theogravity »

BiteCode_dev wrote: post #131
theogravity wrote: post #72

Earlier quoted context omitted.

Thanks. Why is the notion of run and tool separate? Coming from JS, we have the package.json#scripts field and everything executes via a `pnpm run ` command.

Tool ? Maybe you mean uv tool install ? In that case it's something you don't need right now, uv tool is useful, but it's a bonus. It's to install 3rd party utilities outside of the project. There is no equivalent to script yets, althought they are adding it as we speak. uv run exec any command in the context of the venv (which is like a node_modules), you don't need to declare them prior to calling them. e.g: uv run…

I was looking at https://docs.astral.sh/uv/concepts/tools/#the-uv-tool-interf...

Edit: I get it now. It's like npm's `npx` command.

Re: Switching from Pyenv to Uv

#210

Post by throwaway314155 »

lmeyerov wrote: post #102
throwaway314155 wrote: post #74

Earlier quoted context omitted.

Works better than poetry for cuda-versioned pytorch. I don't have overlap with your other domains unfortunately (ML, not data science).

Thanks! I think the comparison for data work is more on conda, not poetry. afaict poetry is more about the "easier" case of pure-python, and not native areas like prebuilt platform-dependent binaries. Maybe poetry got better, but I typically see it more like a nice-to-have for local dev and rounding out the build, but not that recommended install flow for natively-aligned builds. So still curious with folks navigatin…

That's fair. I guess when you see people champion poetry (less so lately) you hope it works as well as pip/conda despite the complexities of pytorch in particular. Finding that the community in particular simply doesn't use that library has a shock of sorts - like this package manager is great, but "your type ain't welcome".

In any case I believe uv is trying to be _the_ solution and Id be pretty surprised if your libs weren't well supported, or on the roadmap at least.

Post reply on HN