PEP 665: outline a potential transition plan

This commit is contained in:
Brett Cannon 2021-12-20 17:00:33 -08:00
parent 79cddd5639
commit 991cc7a295
1 changed files with 91 additions and 0 deletions

View File

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