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) how about that? have a nice day/evening!
On 21 December 2014 at 20:33, Liam Marsh <liam.marsh.home@gmail.com> wrote:
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
On 12/21/2014 9:31 AM, Nick Coghlan wrote:
I thought he was looking for something like the py launcher, implemented for Windows as PEP 397, and discussed for Linux here: https://mail.python.org/pipermail/python-ideas/2014-April/027633.html -- Eric.
On 22 December 2014 at 10:17, Eric V. Smith <eric@trueblade.com> wrote:
I interpreted the second suggestion in light of the first one, which included the point "-any imported py file will be able to choose which version it wants". That's suggesting mixing and matching between versions within the same process space, which is highly unlikely to work correctly (except when modules are specifically designed for that, as indicated by the availability of backported versions on PyPI). Either way, there's a lot of prior art in this space that actually works pretty well once you're aware of its existence, which means future improvements are likely to come in the form of availability, usability, and discoverability improvements for already popular approaches, rather than introducing radical new concepts. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
"""That's suggesting mixing and matching between versions within the same process space, which is highly unlikely to work correctly (except when modules are specifically designed for that, as indicated by the availability of backported versions on PyPI).""" In fact, i was thinking about a small program, which just analize the file for these commentaries, and asks the OS to launch the appropriate "*real" *python environnement, and finishes. This small program will be also be able to chose the appropriate version by scanning the import statements, and seeking for these imported modules in the different environnements installed. 2014-12-22 1:27 GMT+01:00 Nick Coghlan <ncoghlan@gmail.com>:
On Tue, Dec 23, 2014 at 12:06 AM, Liam Marsh <liam.marsh.home@gmail.com> wrote:
If you just want to have the initial script control its version, then that can be done. Put an appropriate shebang at the top of the file, use the py.exe launcher on Windows, and that'll all work.
Not sure what you mean here, but if you use multiple different interpreters all installed concurrently, they'll each have their own separate module trees. Or do you mean different versions of imported libraries (so you could have, for instance, numpy 1.8.2 for this project, and numpy 1.9.1 for another)? In that case, you'd do well to use virtual environments, which cope just fine with this kind of thing. The one thing you *cannot* do easily is have an application request one Python version, and one of its imported modules request a different Python version. Similarly if you have two modules that each import the same third module; the nature of Python's import machinery is such that they have to get the same version (in fact, the same module). Within one execution space, you have to be consistent, or else go through some serious hoop-jumping to keep things separate. ChrisA
On 21 December 2014 at 20:33, Liam Marsh <liam.marsh.home@gmail.com> wrote:
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
On 12/21/2014 9:31 AM, Nick Coghlan wrote:
I thought he was looking for something like the py launcher, implemented for Windows as PEP 397, and discussed for Linux here: https://mail.python.org/pipermail/python-ideas/2014-April/027633.html -- Eric.
On 22 December 2014 at 10:17, Eric V. Smith <eric@trueblade.com> wrote:
I interpreted the second suggestion in light of the first one, which included the point "-any imported py file will be able to choose which version it wants". That's suggesting mixing and matching between versions within the same process space, which is highly unlikely to work correctly (except when modules are specifically designed for that, as indicated by the availability of backported versions on PyPI). Either way, there's a lot of prior art in this space that actually works pretty well once you're aware of its existence, which means future improvements are likely to come in the form of availability, usability, and discoverability improvements for already popular approaches, rather than introducing radical new concepts. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
"""That's suggesting mixing and matching between versions within the same process space, which is highly unlikely to work correctly (except when modules are specifically designed for that, as indicated by the availability of backported versions on PyPI).""" In fact, i was thinking about a small program, which just analize the file for these commentaries, and asks the OS to launch the appropriate "*real" *python environnement, and finishes. This small program will be also be able to chose the appropriate version by scanning the import statements, and seeking for these imported modules in the different environnements installed. 2014-12-22 1:27 GMT+01:00 Nick Coghlan <ncoghlan@gmail.com>:
On Tue, Dec 23, 2014 at 12:06 AM, Liam Marsh <liam.marsh.home@gmail.com> wrote:
If you just want to have the initial script control its version, then that can be done. Put an appropriate shebang at the top of the file, use the py.exe launcher on Windows, and that'll all work.
Not sure what you mean here, but if you use multiple different interpreters all installed concurrently, they'll each have their own separate module trees. Or do you mean different versions of imported libraries (so you could have, for instance, numpy 1.8.2 for this project, and numpy 1.9.1 for another)? In that case, you'd do well to use virtual environments, which cope just fine with this kind of thing. The one thing you *cannot* do easily is have an application request one Python version, and one of its imported modules request a different Python version. Similarly if you have two modules that each import the same third module; the nature of Python's import machinery is such that they have to get the same version (in fact, the same module). Within one execution space, you have to be consistent, or else go through some serious hoop-jumping to keep things separate. ChrisA
participants (4)
-
Chris Angelico -
Eric V. Smith -
Liam Marsh -
Nick Coghlan