[Python-ideas] Fwd: improve compatibility
Nick Coghlan
ncoghlan at gmail.com
Sun Dec 21 15:31:17 CET 2014
On 21 December 2014 at 20:33, Liam Marsh <liam.marsh.home at 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 at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141222/0b12b8f1/attachment.html>
More information about the Python-ideas
mailing list