PEP 722: A couple of additional points for the rejected options (gh-3292)

pep-0722.rst

@@ -391,6 +391,12 @@ Furthermore, TOML, by its nature, is a flexible format intended to support very
 general data structures. There are *many* ways of writing a simple list of
 strings in it, and it will not be clear to inexperienced users which form to use.
 
+Another potential issue is that using a generalised TOML parser can `in some cases
+<https://discuss.python.org/t/pep-722-dependency-specification-for-single-file-scripts/29905/275>`__
+result in a measurable performance overhead. Startup time is often quoted as an
+issue when running small scripts, so this may be a problem for script runners that
+are aiming for high performance.
+
 And finally, there will be tools that expect to *write* dependency data into
 scripts -- for example, an IDE with a feature that automatically adds an import
 and a dependency specifier when you reference a library function. While
@@ -553,6 +559,53 @@ it would be ``requires: pywin32 ; sys_platform == 'win32'``).
 (Thanks to Jean Abou-Samra for the clear discussion of this point)
 
 
+Why not simply manage the environment at runtime?
+-------------------------------------------------
+
+Another approach to running scripts with dependencies is simply to manage those
+dependencies at runtime. This can be done by using a library that makes packages
+available. There are many options for implementing such a library, for example
+by installing them directly into the user's environment or by manipulating
+``sys.path`` to make them available from a local cache.
+
+These approaches are not incompatible with this PEP. An API such as
+
+.. code:: python
+
+    env_mgr.install("rich")
+    env_mgr.install("click")
+
+    import rich
+    import click
+
+    ...
+
+is certainly feasible. However, such a library could be written without the need
+for any new standards, and as far as the PEP author is aware, this has not
+happened. This suggests that an approach like this is not as attractive as it
+first seems. There is also the bootstrapping issue of making the ``env_mgr``
+library available in the first place. And finally, this approach doesn't
+actually offer any interoperability benefits, as it does not use a standard form
+for the dependency list, and so other tools cannot access the data.
+
+In any case, such a library could still benefit from this proposal, as it could
+include an API to read the packages to install from the script dependency block.
+This would give the same functionality while allowing interoperability with
+other tools that support this specification.
+
+.. code:: python
+
+    # Script Dependencies:
+    #     rich
+    #     click
+    env_mgr.install_dependencies(__file__)
+
+    import rich
+    import click
+
+    ...
+
+
 Why not just set up a Python project with a ``pyproject.toml``?
 ---------------------------------------------------------------