On 21 December 2014 at 20:33, Liam Marsh <liam.marsh.home@gmail.com> wrote:

Hello again

a few days later, i wad a new idea:
the user who wants the 2.X modules, the 3.2 and 3.4 modules to work will probably install the three versions.
so, is it possible to have the <somepath>\Python\python34; <somepath>\Python\python32; and <somepath>\Python\python27 dirs, and the <somepath>\Python\PythonAutoVersion program, useing the comment "#py ver XX" to chose which version will take care of it?
(same thing with the IDLE)

You're exploring a space which already has a large array of tools available to address it. In particular, selective application upgrades is one of the features provided by virtual environments. If someone so desires, *.pth files can be used to share modules between different virtual environments (although this isn't a common practice - virtual environments are generally aimed at providing near total isolation of an application's dependency stack from other virtual environments on the system).

You can also already manipulate sys.path freely at runtime, and do even more through custom import hooks.

While I don't actually think the particular approach you suggest here is a good idea (unlike the explicit requirements.txt files of the PyPA ecosystem, you'll likely end up with an utterly unmaintainable system, where nobody has any idea which applications are depending on what), the tools to implement it exist at least as far back as Python 2.7 (by way of the importlib2 backport of the Python 3.4+ import implementation) and even further if you're prepared to work within the constraints of the old C based import implementation, rather than the newer primarily Python one.

So if you'd like to explore this idea further, I'd suggest trying to implement it. Even if you end up agreeing with me that it's a bad idea, you'll likely learn a *lot* about the import system and the full extent of its capabilities in the process (and if you have a blog, others may also be able to learn from the exercise, especially if it's linked from Planet Python).

Another alternative would be to look at ways to layout a directory structure such that API compatible upgrades of dependencies (in a semantic versioning sense) can be shared between different virtual environments. That's a topic for distutils-sig rather than python-ideas, but it's certainly one where a working proof of concept would be a *very* interesting thing to see. (We know it should work in theory, we just haven't had anyone sit down and figure out what the technical details might look like)

Regards,
Nick.

Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia