From 991cc7a2958be369168f5839151aa0a328d0014e Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Mon, 20 Dec 2021 17:00:33 -0800 Subject: [PATCH] PEP 665: outline a potential transition plan --- pep-0665.rst | 91 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) diff --git a/pep-0665.rst b/pep-0665.rst index ec2913feb..530f9c97a 100644 --- a/pep-0665.rst +++ b/pep-0665.rst @@ -647,6 +647,97 @@ they will very likely need a major version release which changes the lock file format. +=============== +Transition Plan +=============== + +In general, this PEP could be considered successful if: + +1. Two pre-existing tools became lockers (e.g. `pip-tools`_, PDM_, + pip_ via ``pip freeze``). +1. Pip became an installer. +1. One major, non-Python-specific platform supported the file format + (e.g. a cloud provider). + +This would show interoperability, usability, and programming +community/business acceptance. + +In terms of a transition plan, there are potentially multiple steps +that could lead to this desired outcome. Below is a somewhat idealized +plan that would see this PEP being broadly used. + + +--------- +Usability +--------- + +First, a ``pip freeze`` equivalent tool could be developed which +creates a lock file. While installed packages do not by themselves +provide enough information to statically create a lock file, a user +could provide local directories and index URLs to construct one. This +would then lead to lock files that are stricter than a requirements +file by limiting the lock file to the current platform. This would +also allow people to see whether their environment would be +reproducible. + +Second, a stand-alone installer should be developed. As the +requirements on an installer are much simpler than what pip provides, +it should be reasonable to have an installer that is independently +developed. + +Third, a tool to convert a pinned requirements file as emitted by +pip-tools could be developed. Much like the ``pip freeze`` equivalent +outlined above, some input from the user may be needed. But this tool +could act as a transitioning step for anyone who has an appropriate +requirements file. This could also act as a test before potentially +having pip-tools grow some ``--lockfile`` flag to use this PEP. + +All of this could be required before the PEP transitions from +conditional acceptance to full acceptance (and give the community a +chance to test if this PEP is potentially useful). + + +---------------- +Interoperability +---------------- + +At this point, the goal would be to increase interoperability between +tools. + +First, pip would become an installer. By having the most widely used +installer support the format, people can innovate on the locker side +while knowing people will have the tools necessary to actually consume +a lock file. + +Second, pip becomes a locker. Once again, pip's reach would make the +format accessible for the vast majority of Python users very quickly. + +Third, a project with a pre-existing lock file format supports at +least exporting to the lock file format (e.g. PDM or Pyflow). This +would show that the format meets the needs of other projects. + + +---------- +Acceptance +---------- + +With the tooling available throughout the community, acceptance would +be shown via those not exclusively tied to the Python community +supporting the file format based on what they believe their users +want. + +First, tools that operate on requirements files like code editors +having equivalent support for lock files. + +Second, consumers of requirements files like cloud providers would +also accept lock files. + +At this point the PEP would have permeated out far enough to be on +par with requirements files in terms of general accpetance and +potentially more if projects had dropped their own lock files for this +PEP. + + ===================== Security Implications =====================