<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 December 2014 at 20:33, Liam Marsh <span dir="ltr"><<a href="mailto:liam.marsh.home@gmail.com" target="_blank">liam.marsh.home@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>Hello again</div><div><br></div>a few days later, i wad a new idea:<div>the user who wants the 2.X modules, the 3.2 and 3.4 modules to work will probably install the three versions.</div><div>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?</div><div>(same thing with the IDLE)</div></div></div></div></div></div></blockquote><br></div><div class="gmail_quote">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).<br><br></div><div class="gmail_quote">You can also already manipulate sys.path freely at runtime, and do even more through custom import hooks.<br></div><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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).<br><br></div><div class="gmail_extra">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)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,<br>Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>