# How do we want to manage additions/removals to the stdlib?

**URL:** <https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681>\
**Category:** Core Development\
**Created:** [September 16, 2021, 8:11pm UTC](https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681 "2021-09-16T20:11:45Z")\
**Posts on this page:** 1\
**Showing post:** 28

<div class="post-metadata">

**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\
**Post date:** [September 17, 2021, 4:32pm UTC](https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681/28 "2021-09-17T16:32:05Z")

</div>

> [@pf\_moore](#):
>
> Generally though, I think that details aside, we’re both broadly uncomfortable with changing `ensurepip` to `ensurelibs` and making it a general mechanism. Is that fair?

I’m actually in favor of something like that!

FWIW, this exact approach (changing standard library stuff to install-by-default packages) and nuances around it were extensively discussed about an year ago, in:

> [@If Python started moving more code out of the stdlib and into PyPI packages, what technical mechanisms could packaging use to ease that transition?](https://discuss.python.org/t/1738):
>
> Sometimes people suggest splitting out parts of the current Python stdlib into independent packages. This could have a number of technical advantages (e.g. being able to ship fixes quicker, creating a supported way for users to slim down their environments by removing unused packages… this is important for containers and mobile apps). But it could also be disruptive for users. So it’s controversial. For example: imagine that multiprocessing gets split out into a standalone package. Whenever a n…

Notably, Python wouldn’t be the first language to do something like this.

> [@If Python started moving more code out of the stdlib and into PyPI packages, what technical mechanisms could packaging use to ease that transition?](https://discuss.python.org/t/if-python-started-moving-more-code-out-of-the-stdlib-and-into-pypi-packages-what-technical-mechanisms-could-packaging-use-to-ease-that-transition/1738/7):
>
> I did some more reading on how Ruby approached this, and it turns out they actually have 4 different levels, not just 3:
> 
> 1. Classic stdlib: code that ships as “part of” the interpreter, no package metadata
> 2. What they call “default gems”: treated like 3rd party packages that are installed by default – they have metadata, versions, can be upgraded – BUT there’s a flag set saying that you can’t remove them, and if you try to `pip uninstall` then it just errors out.
> 3. What they call “bundled gems”: ditto, but without the magic flag, so you can uninstall them if you want.
> 4. Actual 3rd party packages you get from their version of PyPI

I think there are some clear benefits to doing this – which all come down to the fact that we get a _much_ more gradual removal story.

> [@pf\_moore](#):
>
> “what constitutes a Python installation” becomes blurred if people can upgrade, uninstall, or generally mess with, packages that other people consider to be “standard”

Maybe. To me, what we’re doing isn’t blurring the lines of what “Python installation” means, but changing what it means – though, that’s probably wordsmithing. 🙂

---

_[View the full topic](https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681)._