# PEP 665: Specifying Installation Requirements for Python Projects **URL:** \ **Category:** Packaging\ **Created:** [July 30, 2021, 1:04am UTC](https://discuss.python.org/t/pep-665-specifying-installation-requirements-for-python-projects/9911 "2021-07-30T01:04:19Z")\ **Posts on this page:** 1\ **Showing post:** 13
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [July 30, 2021, 11:52pm UTC](https://discuss.python.org/t/pep-665-specifying-installation-requirements-for-python-projects/9911/13 "2021-07-30T23:52:28Z")
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](https://github.com/python/peps/commit/ae53120c3fe65a4e1f88dbdcc321fffe3b8f79d0) 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](https://python.github.io/peps/pep-0665/) 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](https://packaging.python.org/specifications/source-distribution-format/#source-trees) 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`? --- _[View the full topic](https://discuss.python.org/t/pep-665-specifying-installation-requirements-for-python-projects/9911)._