Uv: Running a script with dependencies

https://docs.astral.sh/uv/guides/scripts/#running-a-script-with-dependencies

by Bluestein • 1 year ago

511 172 1 year ago

docs.astral.sh

gopalv• 1 year ago

This is my absolute favourite uv features and the reason I switched to uv.

I have a bunch of scripts in my git-hooks which have dependencies which I don't want in my main venv.

#!/usr/bin/env -S uv run --script --python 3.13

This single feature meant that I could use the dependencies without making its own venv, but just include "brew install uv" as instructions to the devs.

Bluestein6• 1 year ago

I honestly believe this is a killer (killer) feature.-

dwood_dev• 1 year ago

Completely agree. UV for stalled what was going to be a major project to move lots of python to golang. There will still be a lot migrated, but smaller script like things are no longer in scope.

abdusco• 1 year ago

I still write small some scripts in golang when the bootup time is important. Python still takes its time to boot up, and it's not the best tool for the job if it's gonna be called like a shell utility for thousands of files, for example.

alkh4• 1 year ago

If I may interject, does anyone have any idea why the `-S` flag is required? Testing this out on my machine with a BSD env, `/usr/bin/env -S uv run --python 3.11 python` and `/usr/bin/env uv run --python 3.11 python` do the same thing (launch a Python interactive shell). Man page for env doesn't clarify a lot to me, as the end result still seems to be the same("Split apart the given string into multiple strings, and process each of the resulting strings as separate arguments to the env utility...")

Hello71• 1 year ago

https://en.wikipedia.org/wiki/Shebang_(Unix)#Argument_splitt...

Skunkleton• 1 year ago

Its needed on my ubuntu 24.04 system

  $ cat test.sh
  #!/usr/bin/env bash -c "echo hello"
  $ ./test.sh
  /usr/bin/env: ‘bash -c "echo hello"’: No such file or directory
  /usr/bin/env: use -[v]S to pass options in shebang lines
  $ ./test.sh # with -S
  hello

simonw4• 1 year ago

The "declaring script dependencies" thing is incredibly useful: https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...

  # /// script
  # dependencies = [
  #   "requests<3",
  #   "rich",
  # ]
  # ///
  import requests, rich
  # ... script goes here

Save that as script.py and you can use "uv run script.py" to run it with the specified dependencies, magically installed into a temporary virtual environment without you having to think about them at all.

It's an implementation of Python PEP 723: https://peps.python.org/pep-0723/

Claude 4 actually knows about this trick, which means you can ask it to write you a Python script "with inline script dependencies" and it will do the right thing, e.g. https://claude.ai/share/1217b467-d273-40d0-9699-f6a38113f045 - the prompt there was:

  Write a Python script with inline script
  dependencies that uses httpx and click to
  download a large file and show a progress bar

Prior to Claude 4 I had a custom Claude project that included special instructions on how to do this, but that's not necessary any more: https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

minimaxir• 1 year ago

I thought that was a heart emoticon next to requests, for a second.

tayloramurphy• 1 year ago

I mean, who doesn't love requests?

meander_water• 1 year ago

PEP723 is also supported by pipx and hatch, even though uv is (deservedly) getting all the attention these days.

Others like pip-tools have support in the roadmap (https://github.com/jazzband/pip-tools/issues/2027)

zahlman15• 1 year ago

I plan to support it in PAPER as well. A big part of the original rationale for PEP 723 (and 722) was to support people who want to distribute a single Python file to colleagues etc. without worrying about Python packaging (or making a "project"), and allow them to run it with the appropriate dependencies and their own local Python. So while I am trying to make a tool for users (that incidentally covers a portion of developer use cases) rather than developers, this definitely fits.

slt2021• 1 year ago

shebang mode is also incredibly useful and allows execution like ./script.sh

  #!/usr/bin/env -S uv run --script
  # /// script
  # dependencies = [
  #   "requests<3",
  #   "rich",
  # ]
  # ///
  import requests, rich
  # ... script goes here

HellsMaddy• 1 year ago

I really love this and I've been using it a lot. The one thing I'm unsure about is the best way to get my LSP working with inline dependencies.

Usually, when I use uv along with a pyproject.toml, I'll activate the venv before starting neovim, and then my LSP (basedpyright) is aware of the dependencies and it all just works. But with inline dependencies, I'm not sure what the best way to do this is.

I usually end up just manually creating a venv with the dependencies so I can edit inside of it, but then I run the script using the shebang/inline dependencies when I'm done developing it.

sa-code• 1 year ago

This was my contribution to their docs, happy to see people find it useful :)

Havoc• 1 year ago

That’s pretty wild. Thanks for sharing

anthk2• 1 year ago

'env -s' it's not portable.

ImJasonH• 1 year ago

This is cool!

This gave me the questionable idea of doing the same sort of thing for Go: https://github.com/imjasonh/gos

(Not necessarily endorsing, I was just curious to see how it would go, and it worked out okay!)

JetSetIlly• 1 year ago

That's fun. I gave this a try myself. I took a different approach to the solution and used a bash script.

https://gist.github.com/JetSetIlly/97846331a8666e950fc33af9c...

skissane4• 1 year ago

This is cool, but honestly I wish it was builtin language syntax not a magic comment, magic comments are kind of ugly. Maybe some day…

(I realise there are some architectural issues with making it built-in syntax-magic comments are easier for external tools to parse, whereas the Python core has very limited knowledge of packaging and dependencies… still, one of these days…)

frollogaston5• 1 year ago

Funny how all this time, the only commonly-used import syntax like this was in HTML+JS with the <script> tag.

freddie_mercury3• 1 year ago

It IS built-in language syntax. It's defined in the PEP, that's built-in. It's syntax:

"Any Python script may have top-level comment blocks that MUST start with the line # /// TYPE where TYPE determines how to process the content. That is: a single #, followed by a single space, followed by three forward slashes, followed by a single space, followed by the type of metadata. Block MUST end with the line # ///. That is: a single #, followed by a single space, followed by three forward slashes. The TYPE MUST only consist of ASCII letters, numbers and hyphens."

That's the syntax.

Built-in language syntax.

mnky9800n• 1 year ago

uv is so cool. haha. goodbye conda.

linhns• 1 year ago

conda is a completely no-go for me. It’s for data scientists, and only data scientists who do not need to care much about production.

sureglymop• 1 year ago

I hope it's in the same format as requirements files. Because then one could put a comment with a one liner next to it for people who don't have uv.

Something like `pip install -r <(head myscript.py)`. (Not exactly, but you get the idea).

trklausss2• 1 year ago

My question is: if you already have to put the "import" there, why not have a PEP to specify the version in that same import statement, and let `uv` scan that dependency? It's something I never understood.

jraph• 1 year ago

They don't want tools like uv to have to parse Python, which is complex and constantly changes.

zahlman15• 1 year ago

This is addressed in detail the relevant ecosystem-wide standard: https://peps.python.org/pep-0723/#why-not-infer-the-requirem...

My own take:

PEP 723 had a deliberate goal of not making extra work for core devs, and not requiring tools to parse Python code. Note that if you put inline comments on the import lines, that wouldn't affect core devs, but would still complicate matters for tools. Python's import statement is just another statement that occurs at runtime and can appear anywhere in the code.

Besides that, trying to associate version numbers with the imported module is a complete non-starter. Version numbers belong to the distributions[1], which may define zero or more top-level packages. The distribution name may be completely independent from the names of what is imported, and need not even be a valid identifier (there is a standard normalization process, but that still allows your distribution's name to start with a digit, for example).

[1]: You say "packages", but I'm trying to avoid the unfortunate overloading the term. PyPA recommends (https://packaging.python.org/en/latest/discussions/distribut...) "distribution package" for what you download from PyPI, and "import package" for what you import in the code; I think this is a bit unwieldy.

slightwinder• 1 year ago

Save that as script.py and you can use "uv run script.py" to run it with the specified dependencies,

Be aware that uv will create a full copy of that environment for each script by default. Depending on your number of scripts, this could become wasteful really fast. There is a flag "--link-mode symlink" which will link the dependencies from the cache. I'm not sure why this isn't the default, or which disadvantages this has, but so far it's working fine for me, and saved me several gigabytes of storage.

sc077y2• 1 year ago

By default it will create hard links for python packages, so it won't consume any more memory (besides the small overhead of hard links).

zahlman15• 1 year ago

There is a flag "--link-mode symlink" which will link the dependencies from the cache. I'm not sure why this isn't the default

The hard-link strategy still saves disk space — although not as much (see other replies and discussion).

Possible reasons not to symlink that I can think of:

* stack traces in uncaught exceptions might be wonky (I haven't tried it)

* it presumably adds a tiny hit to imports from Python, but I find it hard to imagine anyone caring

* with the hard-linking strategy, you can purge the cache (perhaps accidentally?) without affecting existing environments

crabbone2• 1 year ago

without you having to think about them at all.

Hahahahaha.

Oh. I'm rolling on the floor. Hahahahaha.

How do you never learn? No, honestly, how do you never learn this simple thing: it will break! I will bet my pension on that it will break, and perhaps not you, but some hundreds of developers will have to try to debug and try to figure out where the dependencies went and why they weren't installed correctly, or why something was missing and so on.

There will never be a situation that you don't have to think about something as important as dependencies at all.

simonw4• 12 months ago

Have you used uv run?

willlma• 12 months ago

I'm not a Python dev, but had to write a script the other day and got all cought up with the virtual env stuff. Why can't `uv` just infer the dependencies from the `import ...` line? Why declare the dependencies twice?

clayhacks• 12 months ago

Python import names are not necessarily unique or the name of the package on pypi/pip. Something like PyYaml is imported as yaml, but potentially other packages could supply a slightly different yaml to import

jasonm23• 12 months ago

Most _current_ LLMs know about PEP 723, but you have to say "PEP 723" for them to do it properly.

satertek• 1 year ago

Why doesn't pip support PEP 723? I'm all for spreading the love of our lord and savior uv, but it should be necessary to have an official implementation.

simonw4• 1 year ago

I don't know if there's an official reason, but my guess is that it's slightly out of scope for pip: pip is a packaging installation tool, not a virtual environment managing system.

uv, being both, is a more natural fit for an implementation of that PEP.

Here's a relevant discussion: https://discuss.python.org/t/idea-introduce-standardize-proj...

zahlman15• 1 year ago

It's completely out of scope for pip, which is purely about modifying the set of packages installed into non-transient environments.

Pipx is a wrapper that does more or less what you're looking for (including PEP 723 support), but it arbitrarily refuses to process top-level packages unless they specify an entry point (which makes them "applications" even with abstract dependencies).

I'm planning to support it in PAPER, which can roughly be described as my vision of what pip and pipx, taken together, should have been.

Humphrey• 1 year ago

Oh this looks amazing! I had pretty much stopped using Python for my one-off scripts because of the hassle of dependencies. I can't wait to try this out.

bb885• 1 year ago

I've played with it for a while now, and for one off scripts where python might make more sense than bash, e.g., I write the script this way with uv, and then I only need uv and the script.

One of the complaints about python is that a script stops working over time (because the python installation changes with os updates), and this kinda sorta doesn't make it go away entirely, but what it does do is to eliminate a bunch of the hassle to getting things to work.

bananapub• 1 year ago

this kinda sorta doesn't make it go away entirely

it absolutely can, `uv` can also pin the python interpreter it uses with `requires-python = "==3.11"` or whatever.

nomel3• 1 year ago

Am I crazy for having my default interactive shell "/bin/env python" point to a virtual environment with all the random dependencies that my one off scripts need, so I can just run "python oneoneoff.py"? All of my one off scripts combined use maybe a dozen dependencies. If I need more, I just install them there. I use pyenv, so it's trivial to change the version of python that the interactive shell uses (default or temporary within the current shell).

From my perspective, people seem to make it difficult to use python, more from not understanding the difference between interactive shell and non-interactive shell configurations (if you think the above breaks system tools that use python, then you don't understand the difference, nor that system tools use /bin/python rather than /usr/env python), with a bit of cargo-cult mixed in, more than anything.

om8• 1 year ago

What would you do if some of the deps started to have conflicts in them? Also, what are your plans for migration when you'll need to move from one os version to another?

Implicit solutions like yours have lower cost of entrance, but larger cost of support. uv python scripts just work if you set them up once

m4r71n2• 1 year ago

Oh nice, I was already a happy user of the uv-specific shebang with in-script dependencies, but the `uv lock --script example.py` command to create a lock file that is specific to one script takes it to another level! Amazing how this feels so natural and yet only appeared after 20+ years of Python packaging.

billyjmc• 1 year ago

What’s your use case for locking dependencies on a single script?

One things that’s useful to my organization is that we can then proceed to scan the lockfile’s declared dependencies with, e.g., `trivy fs uv.lock` to make sure we’re not running code with known CVEs.

m4r71n2• 1 year ago

Just better visibility into the dependencies that come with the script (exactly for things like vulnerability scanning that you mention). It's also easier for reproducibility in someone else's environment when I can give them the exact list of dependencies instead of having them resolve it themselves using the inline declarations. Explicit is better than implicit :-)

AceJohnny2• 1 year ago

Note that this only works for single-file scripts.

If you have a project with modules, and you'd like a module to declare its dependencies, this won't work. uv will only get those dependencies declared in the invoked file.

For a multi-file project, you must have a `pyproject.toml`, see https://docs.astral.sh/uv/guides/projects/#managing-dependen...

In both cases, the script/project writer can use `uv add <dependency>`, just in the single-file case they must add `--script`.

heisenzombie• 1 year ago

Quick plug here for a simple Jupyter kernel I created:

https://github.com/tobinjones/uvkernel

It’s a pretty minimal wrapper around “uv” and “iPython” to provide the functionality from the article, but for Jupyter notebooks. It’s similar to other projects, but I think my implementation is the least intrusive and a good “citizen” of the Jupyter ecosystem.

There’s also this work-in-progress:

https://github.com/tobinjones/pep723widget

Which provides a companion Jupyter plugin to manage the embedded script dependencies of noteboooks with a UI. Warning — this one is partially vibe-coded and very early days.

rented_mule• 1 year ago

There is also marimo. For my use cases it has been a fantastic upgrade from Jupyter. I use it in the style of TFA (notebooks are just Python files). In the notebook UI, you can add packages to the script headers. It's so nice to have many notebooks in one directory with independent, but reproducible environments.

Marimo notebooks are easy to diff when committing to git. Plus you get AI coding assistants in the notebook, a reactive UI framework, the ability to run in the browser with Pyodide on WASM, and more. It will also translate your old Jupyter notebooks for you.

For me, what uv is to package managers, marimo is to notebooks.

https://docs.astral.sh/uv/guides/integration/marimo/

Svoka• 1 year ago

More comments the topic - https://news.ycombinator.com/item?id=44369388

Fun with uv and PEP 723

640 points | 227 comments

rr808• 1 year ago

How many package managers can one language have? Its a simple language but setting it up is just incredibly bad. Maybe this is the one or should I wait for the next?

xyse53• 1 year ago

I recommend trying it, it gets a ton of hype but I think for good reason.

This is the one.

roywiggins2• 1 year ago

imo all I usually need is pip-tools and venv, but uv kind of bundles the two together in a very natural way (and is very fast)

nomel3• 1 year ago

Unless you're installing a new version of python, I have trouble seeing how preceding all the normal command with "uv" can be seen as much of a difference.

selcuka3• 1 year ago

I had the same sentiment, but uv seems to have eliminated the competition. Installing uv using your OS package manager is enough as it can also download and install (isolated) Python interpreters as well.

frollogaston5• 1 year ago

Except pip still exists and is default, and even if they adopted uv as default instead, all the legacy stuff takes years to change.

frollogaston5• 1 year ago

I wish they would make uv default and end this game.

pietroppeter• 1 year ago

This is the way

pansa2• 1 year ago

Its a simple language

No, it isn’t. This misconception is common and I don’t know where it comes from.

Python is a very complex language hiding behind friendly syntax.

dagw• 1 year ago

Its a simple language

It really isn't, and that is why the install and setup tools are so problematic. They have to hide and overcome a lot of complexity.

imcritic• 1 year ago

I hate such poor docs that don't explain how things work, and instead prefer hiding behind some "magic".

Constraints can be added to the requested dependency if specific versions are needed:
uv run --with 'rich>12,<13' example.py

Why not mention that this will make uv download specified versions of specified packages somewhere on the disk. Where? Are those packages going to get cached somewhere? Or will it re-download those same packages again and again every time you run this command?

frosting1337• 1 year ago

I mean... it's in the docs?

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

Technetium• 1 year ago

Caching linked on the left: https://docs.astral.sh/uv/concepts/cache/ The index of the Concepts section says: "Looking for a quick introduction to features? See the guides instead."

Maybe there should instead be a link to the Concepts section for people who want more details, but I feel it's fine as it is.

trostaft• 1 year ago

This is pretty great. Passing python code out to my students is usually also confronted with the question of "How do I run it?", which is usually terrible to answer. Now, I can just tell them to get uv (single command) and run it.

SafeDusk• 1 year ago

I am using this feature in my MCP servers and it is a god send! Some details on how I do it can be found at https://blog.toolkami.com/toolkami-shttp-server/.

bb885• 1 year ago

There's a lot of small one off things where deploying uv and the script makes it easy to use. A lot of use cases for golang can be replaced with uv.

hamandcheese• 1 year ago

My favorite part of this is the `exclude-newer` feature, giving you a somewhat reproducible script for very low effort.

jbaber• 1 year ago

I just looked this up yesterday by sheer coincidence and was happy it actually worked. What brought it to your attention today?

mdaniel• 1 year ago

Almost certainly the thread about jqfmt: https://news.ycombinator.com/item?id=44637716

hoherd• 1 year ago

One gotcha I caught myself in with this technique is using it in a script that would remediate a situation where my home has lost internet and needed the router to be power cycled. When the internet is out, `uv` cannot download the dependencies specified in the script, and the script would fail. Thankfully I noticed this problem after writing it but before needing it to actually work, and refactored my setup to pre-install the needed dependencies. But don't make the same mistake I almost made! Don't use this for code that may need to run airgapped! Even with uv caching you may still get a cache miss.

indigodaddy• 1 year ago

But don't you have to only ever run it once to have the deps/venv for subsequent runs?

do_not_redeem• 1 year ago

I don't know if uv garbage collects its cache, but it wouldn't surprise me. Otherwise disk usage would grow indefinitely.

akx• 1 year ago

`uv run --offline` will use cached dependencies and not check for newer versions. Works for `uvx` too, i.e. `uvx --offline ...`.

Bluestein6• 1 year ago

Here's a fun one (says he, in a panic): Will we get to a point where (through fault or, gasp, design) a given AI will generatively code a missing dependency, on the fly - perhaps as a "last ditch" effort?

(I can imagine languages having official LLMs which would more or less "compress/know" enough of the language to be an ...

... import of last resort, of sorts, by virtue of which an approximation to the missing code would be provided.-

zahlman15• 1 year ago

I'm pretty sure we've already reached a point where people generatively code possibly-malicious packages to publish under names of non-existent packages commonly hallucinated by LLMs prompted by other devs.

staplung2• 1 year ago

Love this feature of UV. Here's a one-liner to launch jupyter notebook without even "installing" it:

  uv run --with jupyter jupyter notebook

Everything is put into a temporary virtual environment that's cleaned up afterwards. Best thing is that if you run it from a project it will pick up those dependencies as well.

laurent_du• 1 year ago

I do this all the time as well with `uv run --with ipython --with boto3 ipython`. Great time-saver.

slhck• 1 year ago

Note that it's not really "cleaned up" insofar as there is a uv cache folder that will grow bigger over time as you keep using that feature.

staplung2• 1 year ago

True. It's a good idea to periodically run:

  uv cache clean

Or, if you want to specifically clean just jupyter:

  uv cache clean jupyter

akshayka• 1 year ago

Very nice. Here's a one liner for marimo notebooks:

uvx marimo edit

A one liner with marimo that also respects (and records) inline script metadata using uv:

uvx marimo edit --sandbox my_notebook.py

https://docs.astral.sh/uv/guides/integration/marimo/

ayerajath• 1 year ago

https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...

this is neat af. my throw-away scripts folder will be cleaner now.

exographicskip• 1 year ago

Heard about this! Finally did something with it and I'm happy with how this tiny gist turned out:

https://gist.github.com/pythoninthegrass/e5b0e23041fe3352666...

tl;dr

Installs 3 deps into the uv cache, then does the following:

1. httpx to call get request from github api

2. sh (library) to run ls command for current directory

3. python-decouple to read an .env file or env var

abhisek• 1 year ago

Uh oh. I am thinking all the ways this can be misused to ship malicious dependencies. Pretty much all SCA tools today will be blind to this.

ndr• 1 year ago

why would you ship `uv` though?

Hackbraten5• 1 year ago

I wish there was a straightforward way to let VS Code pick up the venv that uv transparently creates.

Out of the box, the Python extension redlines all the third-party imports.

As a workaround, I have to plunge into the guts of uv's Cache directory to tell VS Code the cached venv path manually, and cross fingers that it won't recreate that venv too often.

nsarrazin• 1 year ago

You can find the env path with `uv python find --script "${filePath}`

I've been working on a VSCode extension to automatically detect and activate the right interpreter: https://marketplace.visualstudio.com/items?itemName=nsarrazi...

ebri• 1 year ago

Could you tell me how you do this in code ? Started using uv in a very old school team and they don’t like uv simply because it’s new. Something like this is what they base it on.

Hackbraten5• 1 year ago

It's super cumbersome so I can't really recommend it for work.

I invoke the "Select Interpreter" action. A file selector opens, then I go to the user cache directory (e.g. ~/.cache on Linux, something like %LOCALAPPDATA%\Cache on Windows). It has a `uv` subdirectory, then I drill further down until I find the directory where uv keeps its venvs. Find the venv that corresponds to your script, then go to its `bin` subdirectory and select the Python executable.

The upside is that you only have to do this once per script.

The downside is that you have to do this once per script.

jjfoooo4• 1 year ago

I also just activate the desired virtual env and start VS Code from the command line within it

ezquerra• 1 year ago

I recently found a small issue with `uv run`. If you run a script from outside the project folder, it looks for the pyproject.toml on the folder from which you are calling `uv run`, not on the folder where the python script is located (or its parents)! Because of that scripts that store their dependencies in a pyproject.toml cannot be run successfully using a “bare” `uv run path/to/my/script.py` from outside the project folder.

You can work around this surprising behavior by always using inline dependencies, or by using the `--project` argument but this requires that you type the script path twice which is pretty inconvenient.

Other than that uv is awesome, but this small quirk is quite annoying.

imjonse• 1 year ago

One case this may not work well is when one of the dependencies is Pytorch. Uv has explicit support for Pytorch ( https://docs.astral.sh/uv/guides/integration/pytorch/ ) but with the script headers I don't see a way to pick the most appropriate wheel index (cpu vs cuda vs rocm)

sam_bristow• 1 year ago

There are a lot of bits and pieces that are clicking into place lately in the Python ecosystem. Recently I've been using the combination of Marimo and these uv script dependencies for building reproducible rwporting and diagnostic tooling for other teams.

damnever• 1 year ago

I like it, and I once thought about this as well:

Python doesn't require a requirements.txt file, but if you don't maintain this file, or neglect to provide one, it could result in broken functionalities - an unfortunate circumstance for a scripting language.

https://twitter.com/_damnever/status/1697247813854503250

poulpy123• 1 year ago

For this use case I would try first to compile the script with nuitka. A single binary is more manageable than doing that

stephenhandley• 1 year ago

This almost as great as how much I love that this gets posted like once every two weeks

jufter• 1 year ago

I'm glad it was reposted so I saw it. I may actually use python for scripting now because uv makes it so easy.

wanderingmind• 1 year ago

As a tangent, one issue I face is how to force cursor to use uv over pip. I have placed it in rules and also explicitly add a rules.yml file in every agent conversation. It still tries to push through pip 4 out of 10 times. Any recommendations on best practice to force cursor to use uv will make a significant dent in productivity

williamdclt• 1 year ago

more of a bandaid than anything else, but maybe something like this might help:

alias pip='echo "do not use pip, use uv instead" && false'

You can put that in your bashrc or zshrc. There's a way to detect if it's a cursor shell to only apply the alias in this case, but I can't remember how off the top of my head!

Bluestein6• 1 year ago

alias pip='echo "do not use pip, use uv instead" && false'

Interesting times, eh?

Who (who!) would have told us all we'd be aliasing terminal commands to *natural language* instructions - for machine consumption, I means. Not for the dumb intern ...

(I am assuming that must have happened at some point - ie. having a verboten command echo "here be dragons" to the PFY ...)

theesm• 1 year ago

I've been doing something similiar utilizing guix shell[0] setting my shebang to e.g.:

#!/usr/bin/env -S guix shell python python-requests python-pandas -- python3

in scripts for including per-script dependencies. This is language agnostic as long as the interpreter and its dependencies are available as guix packages. I think there may be a similiar approach for utilizing nix shells that way as well.

[0] https://guix.gnu.org/manual/en/html_node/Invoking-guix-shell...

zahlman15• 1 year ago

Do these environments reuse existing system-installed packages and hard-link the files?

jemiluv8• 1 year ago

I kinda always struggled to grok python's package management and module system. UV is finally making things more understandable and just as good as the nodejs packaging and module system that I'm more comfortable with. This new feature is kinda awesome. Even surpassing the DX of the node ecosystem.

pavlov• 1 year ago

As a non-Python person, I find “uv” to be a confusing name.

For a long time I assumed it’s a Python wrapper for libuv which is a much older and well-known project. But apparently it’s Python package manager #137 “this one finally works, really, believe me”

cassiogo• 1 year ago

Maybe worth mentioning that ruby has a very similar feature https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...

gkfasdfasdf• 1 year ago

I love this feature of uv but getting linters/language servers to pick up the venv when editing the files is a bit of a pain. I currently have a script 'uv-edit' which I am using to run Neovim with the correct environment:

  #!/bin/bash
  SCRIPT="$1"; shift
  uv sync --quiet --script "$SCRIPT" && exec uv run --python "$(uv python find --script "$SCRIPT")" nvim "$SCRIPT" "$@"

pmarreck• 1 year ago

This is pretty easy to do if you have Nix

https://github.com/pmarreck/yt-transcriber

A commandline youtube transcription tool I built that runs on Mac (nix-darwin) which automatically pulls in all the dependencies it needs

runjake3• 1 year ago

If you’re at all interested in this topic, I strongly recommend you read Simon Willison’s blog at https://simonwillison.net/

He does all the legwork and boils it down into an easily-understandable manner.

He’s also a user her in this thread at simonw. Just an immensely useful guy.

frizlab• 1 year ago

I do this in Swift, using swift-sh[1].

Works well, but the compilation of the dependencies (first run of the script) can be a bit long. A problem which uv (Python) probably won’t have…

[1] https://github.com/xcode-actions/swift-sh

EnnEmmEss• 12 months ago

This is a pretty nice feature which I use quite often. There are still some edge cases where it cannot be used to the fullest extent though. https://github.com/astral-sh/uv/issues/14472 for example.

Uv: Running a script with dependencies

Related Stories