PEP 665: outline a potential transition plan

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
 =====================