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

This is the final version switching to the [run] table approach rather than [project]: PEP 723 – Embedding pyproject.toml in single-file scripts | peps.python.org

8 Likes

Thanks for the update!

I was wondering about the motivation behind run.version. Did you have specific plans for it in Hatch? I read through the PEP and its justification and I’m not quite seeing why it’s important to have in this initial version?

I don’t have much to add other than this section which you have read. I am hesitant to take it out because this is from what I can tell every field that would be relevant to both scripts and directory-type projects, and I would be annoyed if I had to make another PEP or if the PEP for including the table in pyproject.toml files added the field and expanded the script allowance in the same PEP.

I think what’s tripping my brain up is why this has to be standardized as metadata? People use __version__ for this sort of thing and I haven’t seen people calling for this sort of change for code that isn’t installed. I also don’t see how script runners would use the version metadata for anything, e.g. I don’t see how it could benefit caching since you can’t assume someone isn’t actively editing their dependencies between version bumps.

So I’m -0 on the idea unless there’s a bit more motivation behind it being a “nice to have” just because some people like to write down some version number somewhere and so lets just make that a standard. Otherwise this starts down the slippery slope of standardizing any bit of metadata people might want to write down like author name, etc. And at that point we are going back to [project] and deciding we would rather tweak its purpose and required keys.

3 Likes

The version field has been removed.

1 Like

To be clear, if other people come forward and say they have a use case I’m totally happy to be supportive.

2 Likes

@brettcannon I view this PEP as finalized; there will be no further changes.

6 Likes

The idea behind this PEP is very similar to a small tool I created: instld.

My tool allows you to run scripts with the instld command, like this:

instld script.py

If there are third-party library imports inside the script, the libraries are installed automatically. The library name is taken from the name of the imported module. For example, this import will lead to the installation of the “polog” module:

import polog

There are situations when the name of the imported module and the package name are different. In this case, the package name can be specified using a special comment language, here is an example:

import f # instld: version 0.0.3, package fazy

Please note that my implementation does not require the user to have any additional knowledge about venv, pip or PATH. The fact is that all packages for a specific launch are installed in a temporary directory, which is automatically destroyed after the script stops working. By default, the user does not need to think about anything at all, the technology just works.

My opinion about this initiative: this problem is completely solved with the help of my library and does not require improvements directly in CPython.

1 Like

I think you’re misunderstanding. PEP 722 or 723 do not change CPython, but they standardize the information that many tools like yours can read.

1 Like

The mechanism of which you speak has its own section as a rejected idea courtesy of @jeanas: Why not infer the requirements from import statements?

1 Like

@pomponchik, for info: instld seems very similar to @facundo’s fades.

2 Likes

Oh, yes, I misread the purpose of this PEP, sorry.