# PEP 722: Dependency specification for single-file scripts

**URL:** <https://discuss.python.org/t/pep-722-dependency-specification-for-single-file-scripts/29905>\
**Category:** Standards\
**Created:** [July 19, 2023, 12:16pm UTC](https://discuss.python.org/t/pep-722-dependency-specification-for-single-file-scripts/29905 "2023-07-19T12:16:05Z")\
**Posts on this page:** 1\
**Showing post:** 182

<div class="post-metadata">

**Author:** ![h-vetinari](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/h-vetinari/32/1220_2.png) [@h-vetinari](https://discuss.python.org/u/h-vetinari)\
**Post date:** [August 1, 2023, 10:41pm UTC](https://discuss.python.org/t/pep-722-dependency-specification-for-single-file-scripts/29905/182 "2023-08-01T22:41:26Z")

</div>

> [@epage](#):
>
> For context, I’m the author of Rust [eRFC #3424](https://github.com/rust-lang/rfcs/pull/3424) for integrating single-file package support into cargo.

Thanks a lot for the context here @epage! I had no idea that this was such a recent change in cargo.

> [@epage](#):
>
> Most likely, tooling will want to _edit_ and not just read, so consider that workflow as well

I agree (e.g. auto-populate that section from imports in the file), which is why I think it should be in a structured format.

> [@epage](#):
>
> Using `#!` would not be equivalent in Python but putting it in the module’s doc comment […] However, we are concerned about taking that approach because we are wanting allow people to do this with libraries and then we dirty up people’s documentation with implementation details.

Yeah, not recognizing `//!` as a doc comment is my lack of Rust familiarity showing. I don’t see the library case for python though (certainly not in the context of this PEP), and I think a module comment would actually be great for a number of reasons.

> [@pf\_moore](#):
>
> As to the other part of your point, what precisely do you mean by “this”?

There was a concrete example @ofek was responding to…? But to update this in view of @epage’s inputs, how about something à la:

````auto
#!/usr/bin/env python
"""
This is the docstring of my script, which does X.

It has the following requirements:
```toml
[requirements]
requires-python = ">=3.9"
dependencies = [
    "numpy>=1.22.4",
    "requests",
]
```toml
"""
import numpy as np
import requests
print("Hello world!")

````

This would kill several birds with one stone:

- Still easy to extract (some specially marked section of the docstring)
- Still easy to parse _and insert values into programmatically_ (because it’s a toml file)
- Still consistent with `pyproject.toml`
- Self-documenting in an already established, canonical place (plus, the docstring of a script sounds like a _great_ place for putting requirements\[1\])
- Easy to copy & paste to or from actual toml files, because no extra characters (`# `&nbsp;etc.) in front
- Solves the “which Python version does this script need” problem that came up further upthread

This still has about the same list of things up for bikeshedding as above (e.g. what’s the marker around the toml file, is it `[project]` or `[requirements]` or …, etc.), but I hope it’s concrete enough to communicate the intent?

> [@pf\_moore](#):
>
> If you need a full `pyproject.toml`, why wouldn’t you be able to use a project directory? […] we’re bound to get users getting confused because not everything works (e.g. “I put a custom ruff config in `foo.py` and ruff is ignoring it”)

Which is why we’re not talking about the full `pyproject.toml`, but some reduced form of it. Though the ruff config is a great example IMO of why following existing patterns is better than creating new ones, because people will still want to want to lint their single-file scripts, and that way we’d have a canonical place to put the config (as an extension in the future, not for this PEP).

* * *

1. if it has to be within that script

---

_[View the full topic](https://discuss.python.org/t/pep-722-dependency-specification-for-single-file-scripts/29905)._