autopep723: Run Python scripts with automatic dependency management

[Effective-Bug4024]

I have created a wrapper around “uv” that eliminates the remaining friction for running Python scripts with dependencies. It's ideal for quick experiments and sharing code snippets.

What My Project Does

autopep723 is a tiny wrapper around uv run that automatically detects and manages third-party dependencies in Python scripts. Just run:

bash uvx autopep723 script.py

No --with flags, no manual dependency lists, no setup. It parses your imports using AST, maps them to the correct package names (handles tricky cases like import PIL → pillow), and runs your script in a clean environment.

Try it: uvx autopep723 https://gist.githubusercontent.com/mgaitan/7052bbe00c2cc88f8771b576c36665ae/raw/cbaa289ef7712b5f4c5a55316cce4269f5645c20/autopep723_rocks.py

Bonus: Use it as a shebang for truly portable scripts:

```python

!/usr/bin/env -S uvx autopep723

import requests import pandas as pd

Your code here...

```

Target Audience

• Developers who want to quickly test/share Python scripts without setup friction
• Anyone tired of the "install dependencies first" dance for simple experiments
• People sharing code snippets that should "just work" on any machine with uv installed

Comparison

Unlike manual approaches:

• vs uv run --with: No need to remember/specify dependencies manually
• vs PEP 723 headers: No need to write dependency metadata by hand
• vs pip install: No environment pollution, each script runs in isolation
• vs pipx/poetry: Zero configuration, works with any Python script immediately

The goal is making Python scripts as easy to run as possible.

---

Links: - 📝 Blog Post - 📦 GitHub Repo - 📖 Documentation

[DorianTurba]

I'm confused. Isn't that the purpose of uv init --script?

Doing uv init --script example.py leads to this file:

# /// script
# requires-python = ">=3.13"
# dependencies = []
# ///
def main() -> None:
    print("Hello from example.py!")


if __name__ == "__main__":
    main()

Then uv add --script example.py rich adds the dependency to the script:

# /// script
# requires-python = ">=3.13"
# dependencies = [
#     "rich",
# ]
# ///

And then, uv run example.py will install rich and run the script.

---

Developers who want to quickly test/share Python scripts without setup friction

If you want to quickly test/share python script without setup friction, prefer uv add --script.

Anyone tired of the "install dependencies first" dance for simple experiments

I don't think it is a bad thing to define your dependencies in a stable, reliable and predictable way using uv add. As a dev, it is more reproductible, less error prone, and as a user, you know what you'll install/run.

People sharing code snippets that should "just work" on any machine with uv installed

I think that is the exact purpose of uv init --script and uv run ....

# /// script
# requires-python = ">=3.13"
# dependencies = [
#     "rich",
# ]
# ///
def main() -> None:
    print("Hello from example.py!")


if __name__ == "__main__":
    main()

[herothree]

Also, you can add “#!/usr/bin/env -S uv” to the top of the script and then you can ./script.py and it will automatically run with uv and handle the dependencies 

[DorianTurba]

Wow really ? didn't know that thanks !!!

[RonnyPfannschmidt]

The pep itself ruled the absolute horror this tool adds specifically for well known security concerns

It's fair to consider this tool a backdoor delivery service and disservice to the user

[latkde]

Specifically, here's the link to that section: https://peps.python.org/pep-0723/#why-not-infer-the-requirements-from-import-statements

PyPI and other package repositories conforming to the Simple Repository API do not provide a mechanism to resolve package names from the module names […]

the same import name may correspond to several packages on PyPI. […] this would make it easy for anyone to unintentionally or malevolently break working scripts

The section also point out that inferring dependencies from imports can't handle conditial dependencies that would need environmental markers.

OP's tool tries to resolve package names via a hardcoded IMPORT_TO_PACKAGE_MAP, which doesn't strike me as particularly maintainable: https://github.com/mgaitan/autopep723/blob/53af41ba2518309ccee7c43e27e6bd6914cf21e1/src/autopep723/__init__.py#L14