# PEP 582 - Python local packages directory

**URL:** <https://discuss.python.org/t/pep-582-python-local-packages-directory/963>\
**Category:** Packaging\
**Created:** [March 1, 2019, 1:52am UTC](https://discuss.python.org/t/pep-582-python-local-packages-directory/963 "2019-03-01T01:52:44Z")\
**Posts on this page:** 1\
**Showing post:** 391

<div class="post-metadata">

**Author:** ![FFY00](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ffy00/32/4007_2.png) [@FFY00](https://discuss.python.org/u/FFY00)\
**Post date:** [February 9, 2023, 4:56pm UTC](https://discuss.python.org/t/pep-582-python-local-packages-directory/963/391 "2023-02-09T16:56:07Z")

</div>

> [@pf\_moore](#):
>
> I wouldn’t want to use it in pip, _especially_ if it’s not considered “not common practice”.

I mean, we shouldn’t make adding new API a common practice. We should try to fit new use-cases into existing API and very carefully consider when and when not it makes sense.

> [@pf\_moore](#):
>
> As I’ve said a few times, we’re trying to move pip to work consistently with (normal) sysconfig schemes. I don’t see a problem _for pip_ if normal sysconfig schemes omit a path (I’d just say that if the user tries to install to such a scheme, any files in the wheel that would go in that path would be ignored with a warning). But if you feel that sysconfig schemes must have all of the listed paths, I’m fine with that.

This is essentially a normal config scheme for pip, and you will need special handling for the local packages scheme even if you use the existing API anyway.

> [@pf\_moore](#):
>
> I honestly don’t see why ` __pypackages__ ` can’t just have a normal scheme. There’s no reason I can understand why it has to be partial in any case. I guess that’s something @kushaldas needs to answer.

There are two things to consider here.

1. It will leak

2. The current API isn’t ergonomic for this use-case

I guess this mostly depends on how much weight you give to 1). Neither 1) or 2) are blockers, and I think 2)'s weight will be similar for most people.

Personally, I think the separate API is worth it, but it is not required. I’ve opened [Deprecating the `headers` wheel data key](https://discuss.python.org/t/deprecating-the-headers-wheel-data-key/23712) to try to mitigate my worries with 1).

@kushaldas sorry for putting more weight on you, but I think you’ll have to make a call for what to put in the PEP. Or is it possible to give both options to the SC and have them choose?

Resuming, the two options are:

- Normal `sysconfig` scheme
  - Can cause some API breakage
  - It will leak, just like virtual environments ([Deprecating the `headers` wheel data key](https://discuss.python.org/t/deprecating-the-headers-wheel-data-key/23712) mitigates it for the most, but the leakage is still inherent in the design)

- New API (`sysconfig.get_local_packages_paths(base_directory)`)
  - The main downside is it being new API IMO
  - Easier/better to backport (no patching required)

---

_[View the full topic](https://discuss.python.org/t/pep-582-python-local-packages-directory/963)._