# Supporting sdists and source trees in PEP 665

**URL:** <https://discuss.python.org/t/supporting-sdists-and-source-trees-in-pep-665/11869>\
**Category:** Packaging\
**Created:** [November 10, 2021, 6:24pm UTC](https://discuss.python.org/t/supporting-sdists-and-source-trees-in-pep-665/11869 "2021-11-10T18:24:11Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**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:** [November 9, 2021, 7:19pm UTC](https://discuss.python.org/t/supporting-sdists-and-source-trees-in-pep-665/11869/11 "2021-11-09T19:19:09Z")

</div>

> [@mdrissi](#):
>
> The inability to have editable/file installs and hashes in same file very recently ended up making me drop hashes as the lack of editable installs had often led to incorrect developer environments in my team.

But if the code is changing that much and it’s internal code then I don’t see how a lock file benefits you? My understanding of what you’re saying is you really just want a way to list things to install which requirements files already cover as well as PEP 621. But this PEP is not meant to be a general solution for listing anything you may want to install, but to install specific versions of things in a deterministic, secure fashion.

> [@mdrissi](#):
>
> For my use case I would be happy enough if only local/editable installs were permitted to be unhashed.

I would prefer not to support that. If you need to install things from outside of the lock file then that’s fine, but I would rather make it so that whatever is listed in the lock file is considered secure from at least a data integrity POV and not water it down to become just a generic list of things to install.

---

_[View the full topic](https://discuss.python.org/t/supporting-sdists-and-source-trees-in-pep-665/11869)._