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?
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.
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.
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).
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.
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..?
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.
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.
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.
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?
29 comments
[ 3.6 ms ] story [ 70.7 ms ] threadI 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
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
More editable than JSON and far simpler than YAML.
---
The Rust ecosystem also uses TOML.
Instead of:
[project] requires-python = ">=3.11" dependencies = [ "requests<3", "rich", ]
You could write:
{ "project": { "requires-python":">=3.11", "dependencies" : [ "requests<3", "rich" ] }
Gotta think carefully about this... Might upset some coworkers
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.
[1]: https://peps.python.org/pep-0722/
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...
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..?
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.
It's just lightening the load on developers by making the parsing simpler.