PEP 723: Embedding pyproject.toml in single-file scripts (final iteration)

You’re right; I had forgotten. The regex-based version of the spec was a solution to the “needs a parser” requirement – and I believe it is sufficient.

The remaining concerns are mostly about how users would misuse the spec, and potentially get surprising results. I think we can agree on that characterization of the issues solved by using comments rather than strings?

1 Like

FYI I plan on making a decision between PEPs 722 and 723 the week of October 16. If you want a cross-PEP thread to discuss on, see PEP 722 and PEP 723 User Study Discussion .

4 Likes

@brettcannon Am I correct in thinking that the decision is fundamentally TOML versus not and the enclosure may be changed before acceptance?

1 Like

Thank you for sharing this Ed. It’s cool to see Rust also standardizing embedding their native TOML format so that there is only one format developers need to learn.

#!/usr/bin/env cargo
```cargo
[dependencies]
clap = { version = "4.2", features = ["derive"] }
```

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}
```
1 Like

This Rust syntax looks a lot like my proposal for a generic “metadata block” in Python, which I would have personally preferred for both PEPs 722 and 723: PEP 723: Embedding pyproject.toml in single-file scripts - #139 by gwerbin

Rust rules in terms of standardization. IMHO Python should follow the same way, so I much prefer syntax used in PEP 723 over PEP 722

The one thing that itches me in PEP 723, is the references to pyproject and pyproject.toml.
This seems to assume that at some point the [run] table will apply to pyproject.toml too.

In my understanding, it is not established that this will happen so it is confusing.

Would it be sufficient to mention in this PEP that run.dependencies and run.requires-python have the same meaning as in the project table of pyproject.toml so as to facilitate the conversion from one to the other?

Also /// pyproject sounds a bit awkward to me, for the same reason, but also because in my mind a script is not a project.

Sorry to be late to the game. Feel free to ignore if it is too late in the process.

#pyproject-type

Any future PEPs that define additional fields for the [run] table when used in a pyproject.toml file MUST include the aforementioned fields exactly as specified. The fields defined by this PEP are equally as applicable to full-fledged projects as they are to single-file scripts.

The tool table MAY be used by any tool, script runner or otherwise, to configure behavior.

It might be worth tweaking this sentence to reference the rules from PEP 518 for namespacing more explicitly.

Essentially, yes, although I don’t know if I relish the idea of opening up the discussion on the delimiter again if PEP 723 gets accepted (i.e., my concern about string literals has not changed).

1 Like

Fear not, I simply don’t have the time to do that anyway! Also when I implement support in Hatch there will be commands to modify dependencies at that point so users will never be touching metadata directly.

1 Like

I announced my decision as PEP delegate at PEP 722/723 decision.