Ah, sorry. I was thinking about the problem from a different angle, specifically this post from @njs
When developing a new project, I would expect the initial Write a script" stage to start with using just stdlib features, but transition fairly rapidly to using 3rd party packages. Whether the user uses a virtualenv or just the system Python is a matter of preference/experience, but at this point
pip install stuff is the easy and obvious way to go 1.
The problem comes at the transition to “sharing with others” stage. At that point, package install is a post-deploy step, in that you say to the recipient, “here’s my script - you’ll need to install Python and a few dependencies, here’s a
requirements.txt file you can use to do that, give me a shout if you have problems”. It’s still a bit fiddly and manual, but you have a direct interaction with the people you’re sharing your code with, and “oh yes, I forgot I have
foo installed” is just troubleshooting, not a “failed deployment”.
It’s only when you get to step 3 or @njs’s description (deploy a webapp/distribute a standalone app) that you need to consider “deployment” as a formal thing. And at this point you quite possibly already have a routine of “ship the code, install dependencies in the target environment”, so switching to shipping dependencies with the code is a big change - not only do you need to include the dependencies, you also need to add code to your application to fix up
sys.path, and you need to test all this as it’s an architectural change to your code. Not hard, maybe, but it’s a fairly big shift in how you think about what you’re doing (“sharing a script” vs “deploying an application”).
There’s very little in the Python packaging documentation that really helps with this final step. Not many descriptions of how to do it, little or no “best practice” recommendations, and essentially no help for people trying to get things working. So people stick with “what they know works”, the stage 2 “dependency installation as post-deployment step” approach, because it’s a known problem - maybe not easy, but at least familiar.
Having said all of the above, to bring the focus back to “Removing dead batteries from the standard library”, it’s very rare in my experience that the problem is fundamental, insurmountable problems where you can’t use external modules, but rather a succession of annoying road blocks, that add up to the point where it’s just not worth using Python for the task at hand2. Bundling dependencies is pretty much just as annoying a stumbling block in that case as having to get a 3rd party tool added to the target environment, so I’m not sure it makes much difference there.
1 And yes,
pip install stuff isn’t always as easy as we’d like it to be, but there’s lots of people and resources who will help you solve issues, whereas there are very few places you can go for help on bundling stuff…
2 My experience here is with Python as a support tool, not the core business language - if your business is based on Python and you haven’t formulated a workable policy on PyPI modules, let’s just say I’m surprised…