[HN Gopher] PEP 723 - Embedding pyproject.toml in single-file sc...
___________________________________________________________________
PEP 723 - Embedding pyproject.toml in single-file scripts -
peps.python.org
Author : Chmouel
Score : 46 points
Date : 2023-08-06 20:05 UTC (2 hours ago)
(HTM) web link (peps.python.org)
(TXT) w3m dump (peps.python.org)
| woodruffw wrote:
| 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 wrote:
| 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 wrote:
| 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...
| SushiHippie wrote:
| Is there a reason, why the __pyproject__ variable is not a dict
| but a toml string?
| lijok wrote:
| 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 wrote:
| > 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
| lijok wrote:
| I think "easy for humans to edit" is where I mostly
| disagree with. To this day I have not worked with anyone
| that understood the .toml format.
| heinrich5991 wrote:
| Hey. I think I understand the .toml format. What do you
| want to know?
| paulddraper wrote:
| How much time have you spent towards TOML vs -- say --
| YAML?
|
| More editable than JSON and far simpler than YAML.
|
| ---
|
| The Rust ecosystem also uses TOML.
| SushiHippie wrote:
| Thanks this also gave another reason why they didn't use a
| dict for configuration
| https://peps.python.org/pep-0518/#python-literals
| SushiHippie wrote:
| 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" ] }
| lijok wrote:
| No way !
|
| Gotta think carefully about this... Might upset some
| coworkers
| aldanor wrote:
| 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.
| frfl wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| qrian wrote:
| 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.
| thenipper wrote:
| This would be really great. I could see if pairing well with a
| tool like pipx for quickly sharing utility scripts.
| adamckay wrote:
| 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..?
___________________________________________________________________
(page generated 2023-08-06 23:01 UTC)