PEP 723: Embedding pyproject.toml in single-file scripts

Packaging
141

FWIW, I had a usecase today for “this script is useful to write and run with a few PyPI packages”. I took this opportunity to read both the PEPs and do a drive-through pretending that a magical script-run myscript.py command exists to run my script.

My main bit of feedback on PEP 723 is that it involves a lot of boilerplate for what I’d call the “base” case – declaring information in the form recommended by this PEP was a bit tedious and I need to be careful around quoting as well as other details that feel unnecessary (also, I can’t get automated tooling’s assistance today to write that :P).

__pyproject__ = """
[project]
dependencies = [
  "build",
  "pip",
  "httpx",
]
"""

Compared to PEP 722’s:

# Script Dependencies:
#   build
#   pip
#   httpx

Yes, that’s the “base-case” and PEP 723 supports more things today like requires-python. However, it’s still somewhat tedious to declare this information in the proposed format. I would prefer a comment-based/docstring-based approach over a dedicated variable.

From the PEP:

This is in a section about the [build-system] table, so it would be useful to tweak the language to avoid mixing of the concepts of Python’s current pyproject.toml-based build backends and generic “build system” – the title talks about build backends, which none have expressed support for that (based on a quick skim) and the wording here made me double back and be confused why pantsbuild/Pex is being used to show that this is something generic that we should have.

Why not limit build backend behavior? section doesn’t demonstrate any build-backend support for this and it’s unclear how this would even work – since the existing build-backend mechanisms are all based on the existance of a pyproject.toml.

We use SHOULD NOT instead of MUST NOT in order to allow tools to experiment [2] with such functionality before we standardize (indeed this would be a requirement).

Given that the expectation is that this will be something bespoke and specific to the tool, that there’s no prior art (the Rust RFC is an RFC still) and that there’s no clear path to actually having something standardised here, I think it’s a wrong choice to permit [build-system] here. I’d rather expect hatch make-a-script-package myscript.py (subject to renaming) would serve the underlying needs here and there’s really no concept of a build environment or build mechanism independent of whatever-that-tool-does.

PEP 517 was written after multiple efforts in a similar vein, and involved a lot of consideration/discussion about the various design choices within it. I expect that any similar abstraction mechanism would involve a similar order of scrutiny; or at least a decent amount of discussion. :slight_smile:

The specification section was difficult for me to read – the entire section is composed of paragraphs that are 1-4 lines, with not much in terms of clear structure to figure out what exactly the PEP is proposing. Here’s a suggested restructuring (in Markdown, because it’s easier): https://hackmd.io/@pradyunsg/ByLy0px63/edit

In a similar vein, the backwards compatibility section should be a single paragraph from “For example” to “that extra step of indirection.”.

1 Like