PEP 665: Specifying Installation Requirements for Python Projects

[brettcannon]

I’m going to do my best to answer everyone’s question which hasn’t been answered yet. If I missed your question then please let me know.

PEP 665: clarifications based on feedback · python/peps@ae53120 · GitHub should contain all the changes I mention below. PEP 665 – A file format to list Python dependencies for reproducibility of an application | peps.python.org with have the fastest available, rendered version of the updates. I have also updated the copy above.

@njs

shouldn’t needs and required-by use the same verb? needs + needed-by , or requires + required-by ?

Works for me! And I appreciate that the biggest ask so far has been about a name.

@dustin

This PEP is implicitly rejecting PEP 650 as well – I think it’d be good to have an explanation here about why lockfiles should be preferred over what’s proposed in that PEP.

Done.

@uranusjr

in my old proposal back in 2019, I used an empty string to designate the top level dependencies. This never caught on back then, but I’d definitely not object if we bring it back

Would this eliminate the top-level needs key?

@steve.dower

Could you add a short summary putting this file in context given today’s de facto state of the world?

@steve.dower

Why require a directory?

What if my lock file for development is different than production? If if I have different production lock files? What if I want a Read the Docs lock file, testing lock file, dev lock file, and prod lock file and they are all subtly different?

We could try to cram all of this into a single file and come up with some way to deal with conflicts (e.g. separate sections for each “grouping”), but we chose a file as it more visibly separated things and keeps the individual files at least a little smaller than they might otherwise be for trying to navigate.

@steve.dower

What should consumers (installers) written today do if the version field is not 1?

Error out IMO.

@steve.dower

Where file:// is mentioned, could it be file: instead and allow relative paths?

Sure (that was my mistake in writing it that way to begin with).

@steve.dower

type="source tree" is the space really necessary? Would type="sources" suffice?

It’s not necessary, but “source tree” is an official, defined term which matches what this is meant for.

@steve.dower

Any consideration for having a requested_version field in package references (alternatively, “constraint”)?

How is this different than having that specified in needs?