PEP 665, take 2 -- A file format to list Python dependencies for reproducibility of an application

Packaging
37

I would argue that use cases for absolute file paths are very scarce… It requires the application (and its lock-file) to be placed inside a bigger, non-relocatable, file structure that is replicated in every installation. And that is very tricky to maintain…

On the other hand there are 2 common use cases for relative file paths:

  1. The application “vendorises” patched versions of libraries in subfolders (either as folder/submodule or sdist/wheel file – e.g. ./_patched/unmaintained_lib_that_needs_patching)
  2. The application is developed as part of a “monorepo” and dependencies are in “sibling directories” (e.g. ../mylib)

If support for relative paths is inconsistent, maybe a good solution is to define a “string replacement”,
for example ${__LOCKFILE_DIR__} (or any name really) that expands to the absolute path of the directory where the lock file is placed, and allow people to do:

  • url = "file://${__LOCKFILE_DIR__}/_vendor/lib" or
  • url = "file://${__LOCKFILE_DIR__}/../mylib".

This kind of string can be solved via

  • os.path.normpath(string.Template(url).safe_substitute(__LOCKFILE_DIR__=...)),
    or even os.path.normpath(url.replace("${__LOCKFILE_DIR__}", ...))
    (could be defined in the PEP)

which is doable even if the installer is not implemented in Python.

1 Like