PEP 665: make using PEP 621 as input a rejected idea
This commit is contained in:
parent
1d3deac884
commit
d6c4aa7a8e
24
pep-0665.rst
24
pep-0665.rst
|
@ -756,6 +756,17 @@ to reflect the granularity that dependencies can truly be specified
|
|||
at.
|
||||
|
||||
|
||||
----------------------------------
|
||||
Specify Where Lockers Gather Input
|
||||
----------------------------------
|
||||
|
||||
This PEP does not specify how a locker gets its input. An initial
|
||||
suggestion was to partially reuse PEP 621, but due to disagreements
|
||||
on how flexible the potential input should be in terms of specifying
|
||||
things such as indexes, etc., it was decided this would best be left
|
||||
to a separate PEP.
|
||||
|
||||
|
||||
===========
|
||||
Open Issues
|
||||
===========
|
||||
|
@ -796,19 +807,6 @@ probably capable of providing wheels, making support for sdists that
|
|||
much less important/useful.
|
||||
|
||||
|
||||
----------------------------------
|
||||
Specify Where Lockers Gather Input
|
||||
----------------------------------
|
||||
|
||||
This PEP currently does not specify how a locker gets its input. It
|
||||
could be possible to support a subset of PEP 621 such that
|
||||
``project.requires-python`` and ``project.dependencies`` are read
|
||||
from ``pyproject.toml`` and automatically used as input if provided.
|
||||
But this or some other practice could also be left as something to
|
||||
grow organically in the community and making that the standard at a
|
||||
later date.
|
||||
|
||||
|
||||
===============
|
||||
Acknowledgments
|
||||
===============
|
||||
|
|
Loading…
Reference in New Issue