PEP 723 – Embedding pyproject.toml in single-file scripts – peps.python.org

https://peps.python.org/pep-0723/

by Chmouel • 3 years ago

69 28 3 years ago

peps.python.org

Is there a reason, why the __pyproject__ variable is not a dict but a toml string?

frfl• 3 years ago

Maybe because then you can just inline a pyproject text without any extra effort and the existing tooling for pyproject parsing can work in both cases?

SushiHippie5• 3 years ago

Yeah copying a pyproject.toml seems like a valid case. But I'd guess that the toml will be parsed to something like a dict anyway after reading the file/string.

Verath• 3 years ago

I think they do kind of answer that under the "Why not use (possibly restricted) Python syntax?".

I understand their reasoning to be that it would require other tools to know how to parse python. Which is much more difficult than parsing toml

SushiHippie5• 3 years ago

Ah okay, I read this but I've understood it in another way. I thought they meant using multiple variables could become a problem. But I guess it makes some sense to not parse the python ast tree but to parse with a regex.

lijok3• 3 years ago

It's probably because pyproject.toml is the direction in which the python ecosystem is going.

On that note, I will never understand why they chose .toml instead of just json or yaml..

Denvercoder9• 3 years ago

On that note, I will never understand why they chose .toml instead of just json or yaml..

https://peps.python.org/pep-0518/#other-file-formats

SushiHippie5• 3 years ago

Yes, but you can write a pyproject toml file also as a python dictionary.

Instead of:

[project] requires-python = ">=3.11" dependencies = [ "requests<3", "rich", ]

You could write:

{ "project": { "requires-python":">=3.11", "dependencies" : [ "requests<3", "rich" ] }

aldanor• 3 years ago

YAML is one of the most ambiguous formats out there, and definitely an overkill for what's needed to describe metadata.

JSON - not the most convenient to use for human beings, too much quoting, not too git friendly because of disallowed trailing commas, etc.

TOML sits somewhere inbetween, easy to write but the spec is very short; also being used in Rust and a few other places.

bandyaboot• 3 years ago

It does seem like over-complicating things for a dynamic language not to use itself as the standard configuration format.

woodruffw2• 3 years ago

For some additional context: PEP 722[1] proposes a similar technique, but only for the script's requirements (and not the full TOML-formatted package metadata).

[1] https://peps.python.org/pep-0722/

frays• 3 years ago

PEP 723 should be preferred over 722. Using a .toml format makes a lot more sense over the arbitrary `Script Dependencies:` line in a comment block.

woodruffw2• 3 years ago

Both come with upsides and downsides: it's worth reading the discussion threads[1][2] on both!

I think I agree with you, but it's worth noting that embedding TOML into a here-string also raises some problems: it means that a maximally correct parser will need to handle string continuations, for example. It's also incompatible with what existing tools do, which is consume an unspecified form of PEP 722's syntax. These are not insurmountable problems, but they are reasonable considerations.

[1] https://discuss.python.org/t/pep-722-dependency-specificatio...

[2] https://discuss.python.org/t/pep-723-embedding-pyproject-tom...

thenipper• 3 years ago

This would be really great. I could see if pairing well with a tool like pipx for quickly sharing utility scripts.

adamckay• 3 years ago

This will be useful, and definitely handy when sharing random scripts with a defined structure for its requirements. I've struggled to give scripts to non-developers to run recently and between getting them to configure a virtualenv and install dependencies by hand to using `pipx` it's been a pain so hopefully this will alleviate some if it in the future.

Not sure, however, that I buy the argument that it's going to be simpler for non-programmers to use TOML embedded inside a multiline string versus using something along the lines of requirements.txt - there's going to be absolutely zero syntax highlighting so things like missing quotes or bracket's will need to be carefully identified.

There's also going to be inevitable differences between `__pyproject__` and `pyproject.toml` which could lead to more confusion, such as the `readme` key - that's likely to be useful to include some help information alongside your script so it's self documenting, but in `pyproject.toml` it must refer to another file and in `__pyproject__` I'd assume it can itself be a multiline string..?

qrian• 3 years ago

It's interesting that they tested for AI code completion compatibility. It makes sense as AI code completion is now a big part of tooling and standards should accomodate for common tools.

memefrog• 3 years ago

AI code completion is a complete grift.

thatxliner• 3 years ago

That’s funny because literally today I wrote a script runner that implements PEP 722

noirscape• 3 years ago

One thing I don't quite get is why the proposal here is so insistent on triple quoted strings only. Shouldn't a \n formatted string also be considered valid? Its practically just a string after all.

Other than that, this isn't a bad proposal. Generally for single-file scripts, figuring out the imports isn't too difficult but you do have the occasionally weirdly named pypi package vs installed import package.

tracnar• 3 years ago

The syntax is restricted so the toml content can be extracted without actually parsing the Python file, a regex is enough.

Doxin• 3 years ago

I think the reason for being so specific about using tripple quoted strings is that this stuff needs to be parsed out without running it through the interpreter. e.g. pip needs to be able to fish out the pyproject.toml data to install dependencies before running the script is even going to work.

It's just lightening the load on developers by making the parsing simpler.

theanonymousone• 3 years ago

Will it be part of the Python distribution (3.12?) or a specification for an independent package? Is there already an implementation, apart from the GitHub repository referenced in the article?

PEP 723 – Embedding pyproject.toml in single-file scripts – peps.python.org

Related Stories