8 ms·

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

69 points by Chmouel 3y ago

qrian 3y 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 3y ago
  AI code completion is a complete grift.
deleted 3y ago
[deleted]
thatxliner 3y ago
That’s funny because literally today I wrote a script runner that implements PEP 722
noirscape 3y 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 3y ago
  The syntax is restricted so the toml content can be extracted without actually parsing the Python file, a regex is enough.
- Doxin 3y 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 3y 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?
SushiHippie 3y ago
Is there a reason, why the __pyproject__ variable is not a dict but a toml string?
- bandyaboot 3y ago
  It does seem like over-complicating things for a dynamic language not to use itself as the standard configuration format.
- frfl 3y 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?
  - SushiHippie 3y 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 3y 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
  - SushiHippie 3y 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.
- lijok 3y 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..
woodruffw 3y 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/ https://peps.python.org/pep-0722/
- frays 3y 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.
  - woodruffw 3y 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-specification-for-single-file-scripts https://discuss.python.org/t/pep-722-dependency-specificatio... [2]: https://discuss.python.org/t/pep-723-embedding-pyproject-toml-in-single-file-scripts https://discuss.python.org/t/pep-723-embedding-pyproject-tom...
thenipper 3y ago
This would be really great. I could see if pairing well with a tool like pipx for quickly sharing utility scripts.
adamckay 3y 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..?

69 points by Chmouel 3y 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 3y ago
AI code completion is a complete grift.

deleted 3y ago

[deleted]

thatxliner 3y ago

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

noirscape 3y 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 3y ago
The syntax is restricted so the toml content can be extracted without actually parsing the Python file, a regex is enough.
Doxin 3y 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 3y 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?

SushiHippie 3y ago

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

bandyaboot 3y ago
It does seem like over-complicating things for a dynamic language not to use itself as the standard configuration format.
frfl 3y 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?
- SushiHippie 3y 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 3y 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
- SushiHippie 3y 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.
lijok 3y 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..

woodruffw 3y 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/ https://peps.python.org/pep-0722/

frays 3y 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.
- woodruffw 3y 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-specification-for-single-file-scripts https://discuss.python.org/t/pep-722-dependency-specificatio... [2]: https://discuss.python.org/t/pep-723-embedding-pyproject-toml-in-single-file-scripts https://discuss.python.org/t/pep-723-embedding-pyproject-tom...

thenipper 3y ago

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

adamckay 3y 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..?