Oh auto-3rd party modules is a mess. Suggesting updating only the interpreter. We can have a pre-scan which warns the user that upgrading will make the following packages no longer compatible. But that's one aim of venvs i think, is to confine packages to projects, not to the interpreter.
No java does not have such a feature, it's a suggestion that's unrelated to Java. For distributing to clients, you don't rely on the user interpreter for packages. As far as I know, some companies select let's say version 1.0.5 of a library, and ... they keep it internal, they might modify it as desired. It becomes a home pet. They distribute this version with their project. Even if the library is at 2. they use the modified 1. for increased stability. That's one extreme. Having a sort of .jar running with the system interpreter concerns syntax and enforced standards. To further ease dist, much work is required to be done on the project format itself. If i remember well, a PEP proposed to install 3rd party packages in a folder in the project, which might further enhance the process. Having a Python-specific executable allows you to go to whatever length you desire to make project bundling an easy task. The other effort is to get your interpreter/VM running on as many hardwares as possible. This includes the effort to make it lighter, faster etc. It might entails the complete removal of 3rd party packaging interpreter side or not using it when running the specific executable. I believe Python should be able to run on any device. I believe that my Python code should go everywhere. It pains me to see a project not choosing Python as an add-on scripting language due to the size of the interpreter or things of the sort. -- https://mail.python.org/mailman/listinfo/python-list