Re: [Python-Dev] Proposal for virtualenv functionality in Python
Ian Bicking wrote: This is a proto-proposal for including some functionality from virtualenv in Python itself. I'm not entirely confident about what I'm proposing, so it's not really PEP-ready, but I wanted to get feedback... First, a bit about how virtualenv works (this will use Linux conventions; Windows and some Mac installations are slightly different): * Let's say you are creating an environment in ~/env/ * /usr/bin/python is *copied* to ~/env/bin/python * This alone sets sys.prefix to ~/env/ (via existing code in Python) * At this point things are broken because the standard library is not available * virtualenv creates ~/env/lib/pythonX.Y/site.py, which adds the system standard library location (/usr/lib/pythonX.Y) to sys.path * site.py itself requires several modules to work, and each of these modules (from a pre-determined list of modules) is symlinked over from the standard library into ~/env/lib/pythonX.Y/ * site.py may or may not add /usr/lib/pythonX.Y/site-packages to sys.path * *Any* time you use ~/env/bin/python you'll get sys.prefix of ~/env/, and the appropriate path. No environmental variable is required. * No compiler is used; this is a fairly light tool I have a tool that also creates a virtualized Python environment, but doesn't solve the problem as thoroughly as virtualenv. I limp along by tweaking PYTHONUSERBASE and PYTHONPATH. I'm very interested in seeing something like this make it in to Python. A few inline comments: * I'd rather ~/env/bin/python be a symlink instead of copying it. The thread discussing Windows suggests that we shouldn't use symlinks there. I'd say either copying or symlinking pythonv should be supported, and on Windows we recommend copying pythonv.exe. * Compiling extensions can be tricky because code may not find headers (because they are installed in /usr, not ~/env/). I think this can be handled better if virtualenv is slightly less intrusive, or distutils is patched, or generally tools are more aware of this layout. Conversely, headers may be installed in ~/env and not /usr. The compiler should probably look in both places. But IIUC telling the compiler how to do that is only vaguely standardized--Microsoft's CL.EXE doesn't seem to support any environment variable containing an include /path/. I suspect solving this in a general way is out-of-band for pythonv, but I'm willing to have my mind changed. Certainly pythonv should add its prefix directory to LD_LIBRARY_PATH on Linux. Additionally, the binary will look for a configuration file. I'm not sure where this file should go; perhaps directly alongside the binary, or in some location based on sys.prefix. The configuration file would be a simple set of assignments; some I might imagine: * Maybe override sys.prefix * Control if the global site-packages is placed on sys.path * On some operating systems there are other locations for packages installed with the system packager; probably these should be possible to enable or disable * Maybe control installations or point to a file like distutils.cfg I'm unexcited by this; I think simpler is better. pythonv should virtualize environments layered on top of python, and should have one obvious predictable behavior. Certainly if it supports a configuration file pythonv should run without it and pick sensible defaults. What are the use cases where you need these things to be configurable? Let me propose further about python and pythonv: * As Antoine suggested, the CPython interpreter should sprout a new command-line switch, --prefix, which adds a new prefix directory. * pythonv's purpose in life is to infer your prefix directory and run pythonX.X --prefix prefixdir [ all args it got ... ]. * Should pythonv should be tied to the specific Python executable? If you run install pythonv as python, should it look for python or explicitly look for the specific Python it shipped with, like python3.2? I suspect the latter though I'm no longer sure. I'm one of those folks who'd like to see this be stackable. If we tweak the semantics just a bit I think it works: * pythonv should inspect its --prefix arguments, as well as passing them on to the child python process it runs. * When pythonv wants to run the next python process in line, it scans the path looking for the pythonX.X interpreter but /ignores/ all the interpreters that are in in a --prefix bin directory it's already seen. * python handles multiple --prefix options, and later ones take precedence over earlier ones. * What should sys.interpreter be? Explicit is better than implicit: the first pythonv to run also adds a --interpreter argv[0] to the front of the command-line. Or they could all add it and python only uses the last one. This is one area where python vs python3.2 makes things a little complicated. I'm at PyCon and would be
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings la...@hastings.org wrote: * I'd rather ~/env/bin/python be a symlink instead of copying it. The thread discussing Windows suggests that we shouldn't use symlinks there. I'd say either copying or symlinking pythonv should be supported, and on Windows we recommend copying pythonv.exe. Sure, on Windows this is clearly the case. I'm not sure if it's worth supporting elsewhere. One problem with copying is that (a) you don't know where it is copied from (requiring extra information somewhere) and (b) if there is a minor Python release then things break (because you've copied an old interpreter). Probably there should be a check to catch (b) and print an appropriate (helpful) error. * Compiling extensions can be tricky because code may not find headers (because they are installed in /usr, not ~/env/). I think this can be handled better if virtualenv is slightly less intrusive, or distutils is patched, or generally tools are more aware of this layout. Conversely, headers may be installed in ~/env and not /usr. The compiler should probably look in both places. But IIUC telling the compiler how to do that is only vaguely standardized--Microsoft's CL.EXE doesn't seem to support any environment variable containing an include /path/. I suspect solving this in a general way is out-of-band for pythonv, but I'm willing to have my mind changed. Certainly pythonv should add its prefix directory to LD_LIBRARY_PATH on Linux. Yes, it might be possible to change distutils to be aware of this, and some things will work okay as a result. Some things will really require changes to the problematic project's setup.py to support this. Additionally, the binary will look for a configuration file. I'm not sure where this file should go; perhaps directly alongside the binary, or in some location based on sys.prefix. The configuration file would be a simple set of assignments; some I might imagine: * Maybe override sys.prefix * Control if the global site-packages is placed on sys.path * On some operating systems there are other locations for packages installed with the system packager; probably these should be possible to enable or disable * Maybe control installations or point to a file like distutils.cfg I'm unexcited by this; I think simpler is better. pythonv should virtualize environments layered on top of python, and should have one obvious predictable behavior. Certainly if it supports a configuration file pythonv should run without it and pick sensible defaults. What are the use cases where you need these things to be configurable? * Override sys.prefix: allow you to put the binary in someplace other than, say, ~/env/bin/python and still support an environment in ~/env/. Also the use case of looking for libraries in a location based on the interpreter name (not the containing directory), like supporting /usr/bin/python2.7 and /usr/bin/python2.7-dbg. * Control global site-packages: people use this all the time with virtualenv. * Other locations: well, since Ubuntu/Debian are using dist-packages and whatnot, to get *full* isolation you might want to avoid this. This is really handy when testing setup instructions. * Control installations: right now distutils only really looks in /usr/lib/pythonX.Y/distutils/distutils.cfg for settings. virtualenv monkeypatches distutils to look in sys.prefix/lib/pythonX.Y/distutils/distutils.cfg in addition, and several people use this feature to control virtualenv-local installation. Let me propose further about python and pythonv: * As Antoine suggested, the CPython interpreter should sprout a new command-line switch, --prefix, which adds a new prefix directory. OK; or at least, it seems fine that this would be equivalent. * pythonv's purpose in life is to infer your prefix directory and run pythonX.X --prefix prefixdir [ all args it got ... ]. I don't see any reason to call the other Python binary, it might as well just act like it was changed. sys.executable *must* point to the originally called interpreter anyway. * Should pythonv should be tied to the specific Python executable? If you run install pythonv as python, should it look for python or explicitly look for the specific Python it shipped with, like python3.2? I suspect the latter though I'm no longer sure. Experience shows the latter, plus this would only really make sense if you really called the other interpreter (which I guess you could if you also added an --executable option or something to fix sys.executable). If you did that, then maybe it would be possible to do with PEP 3147 ( http://www.python.org/dev/peps/pep-3147/) since that makes it more feasible to support multiple Python versions with a single set of installed libraries. 3147 is important (and that it be backported to 2.7). I have to think about it a bit... but maybe with this it would be
Re: [Python-Dev] Proposal for virtualenv functionality in Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregory P. Smith wrote: On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby p...@telecommunity.com wrote: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. +1 for having the conf file in the same directory as the pythonv esecutable (yes, I know it isn't FHS compatible, but virtualevn is kind of antithetical to the spirit of FHS anyway). (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) Some recent discussion pointed out that vista and win7 ntfs actually supports symlinks. the same question about determining where it was launched from may still hold there? (and we need this to work on xp). How often do windows users need something like virtualenv? (Asking for experience from windows users of all forms here). I personally can't imagine anyone that would ever use a system generic python install from a .msi unless they're just learning python. I would hope people would already use py2exe or similar and include an entire CPython VM with their app with their own installer but as I really have nothing to do with windows these days I'm sure I'm wrong. What about using virtualenv with ironpython and jython? does it make any sense in that context? how do we make it not impossible for them to support? virtualenv already works with jython: I used it just the other day to test installing BFG in a jython sandbox (which also worked fine). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuBgLgACgkQ+gerLs4ltQ5x8ACghv5gXczECU+gKHmZg6L+LYA1 CWMAn0j99m9TtE0LeQ2Z9zOUpse3P53b =l+uZ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Ian Bicking wrote: On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings la...@hastings.org mailto:la...@hastings.org wrote: * Override sys.prefix: allow you to put the binary in someplace other than, say, ~/env/bin/python and still support an environment in ~/env/. Also the use case of looking for libraries in a location based on the interpreter name (not the containing directory), like supporting /usr/bin/python2.7 and /usr/bin/python2.7-dbg. I'm new to this: why would you want to change sys.prefix in the first place? Its documentation implies that it's where Python itself is installed. I see two uses in the standard library (trace and gettext) and they both look like they'd get confused if sys.prefix pointed at a virtualized directory. * Control global site-packages: people use this all the time with virtualenv. * Other locations: well, since Ubuntu/Debian are using dist-packages and whatnot, to get *full* isolation you might want to avoid this. This is really handy when testing setup instructions. * Control installations: right now distutils only really looks in /usr/lib/pythonX.Y/distutils/distutils.cfg for settings. virtualenv monkeypatches distutils to look in sys.prefix/lib/pythonX.Y/distutils/distutils.cfg in addition, and several people use this feature to control virtualenv-local installation. Okey-doke, I defer to your experience. Obviously if this is going into Python we can do better than monkeypatching distutils. * pythonv's purpose in life is to infer your prefix directory and run pythonX.X --prefix prefixdir [ all args it got ... ]. I don't see any reason to call the other Python binary, it might as well just act like it was changed. sys.executable *must* point to the originally called interpreter anyway. If by this you mean pythonv should load the Python shared library / DLL directly, that would make it impossible to stack environments. Which I'm still angling for. /larry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On Feb 21, 2010, at 01:51 PM, Tres Seaver wrote: +1 for having the conf file in the same directory as the pythonv esecutable (yes, I know it isn't FHS compatible, but virtualevn is kind of antithetical to the spirit of FHS anyway). Which is okay, right? because virtualenv is really about development and the FHS is really about installation. Is that what you meant by antithetical? -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: On Feb 21, 2010, at 01:51 PM, Tres Seaver wrote: +1 for having the conf file in the same directory as the pythonv esecutable (yes, I know it isn't FHS compatible, but virtualevn is kind of antithetical to the spirit of FHS anyway). Which is okay, right? because virtualenv is really about development and the FHS is really about installation. Is that what you meant by antithetical? FHS is about keeping the system components in known location, and mandates stuff like separation of binaries, configuration, shared libs, data, etc.. virtualenv is about building an envirnoment which is insultated from the system components (and avoids polluting them). Putting the config file next to the binary would be verboten under the FHS, but I don't think it is relevant. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuBqQMACgkQ+gerLs4ltQ6hsACeJl44YWskNdPiPhAkLcu0RSom sXAAn0/8dD++Z17VvtknD2hGQcYRGOPX =WXX4 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Larry Hastings: But IIUC telling the compiler how to do that is only vaguely standardized--Microsoft's CL.EXE doesn't seem to support any environment variable containing an include /path/. The INCLUDE environment variable is a list of ';' separated paths http://msdn.microsoft.com/en-us/library/36k2cdd4%28VS.100%29.aspx Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Glenn Linderman wrote: Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. So if you can't test it, why would you state it as a fact... and then back-pedal? :) It was a question, not a statement! Plus, I figured I could con someone into testing it for me. Mission accomplished. :) Thanks for investigating. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Glenn Linderman wrote: Windows also has hard-links for files. A lot of Windows tools are completely ignorant of both of those linking concepts... resulting in disks that look to be over capacity when they are not, for example. Here comes my nit picking mode again. ;) First of all the links are not a feature of the operating system but rather a feature of the file system (version). The fact is valid for Unix as well but most Unix file systems support hard- and soft links anyway. To my best knowledge links are only supported on NTFS. FAT doesn't support links and IIRC it's not possible to create a hard link on a remote file system. NTFS supports POSIX style hard links of files that are limited to one file system. It's not possible to create a hard link that points to another file system. This constrain also applies to Unix. Since Windows 2000 NTFS has junction points that work similar to symbolic link on directories within a local file system. Junction points should be avoided because the Windows explorer can't handle them properly until Windows Vista. Since Vista NTFS also has symbolic links that work across file systems and can point to remote locations and non-existing files, too. However only administrators are allowed to create symlinks on Vista. Vista has no builtin tool to lift the restriction for ordinary users. You have to grab some files from Windows Server 2003 for the task. As long as Python supports XP we shouldn't use symlinks on Windows for stuff like virtualenv. The python.exe on Windows is small (just a few kb) since it is linked against the dll. Let's copy it and we are on the safe side. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Christian Heimes wrote: good stuff deleted As long as Python supports XP we shouldn't use symlinks on Windows for stuff like virtualenv. The python.exe on Windows is small (just a few kb) since it is linked against the dll. Let's copy it and we are on the safe side. +1. Even if we dropped XP I'm not sure moving to symlinks for this would be the right thing to do. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
First of all the links are not a feature of the operating system but rather a feature of the file system (version). That's not really true. Even though ext2 supports symbolic links, on XP with an ext2 driver, you still don't get symbolic links. So you need the feature *both* in the operating system and the file system. The fact is valid for Unix as well but most Unix file systems support hard- and soft links anyway. As do most Unix implementations - but I still remember Unix implementations which didn't support symlinks, not even in the API. To my best knowledge links are only supported on NTFS. FAT doesn't support links and IIRC it's not possible to create a hard link on a remote file system. The latter is not really true: NFS most certainly supports hard links. I can't try right now, but I would be surprised if SMB didn't support both symbolic and hard links, given the right server and client versions. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Martin v. Löwis wrote: The latter is not really true: NFS most certainly supports hard links. I can't try right now, but I would be surprised if SMB didn't support both symbolic and hard links, given the right server and client versions. I've never seen nor used NFS on Windows so I can't comment on NFS. Some time ago I did some experiments with links but I wasn't able to create a hard link on a remote SMB server. However Wikipedia claims that CIFS support hard and sym links. Your conclusion regarding server and client version sounds plausible. In my humble opinion links are aliens on Windows. I wouldn't use them to implement virtualenv. :) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Am 20.02.2010 06:37, schrieb Michael Foord: -- http://www.ironpythoninaction.com Nice signature! On 19 Feb 2010, at 22:52, Eric Smith e...@trueblade.com wrote: Glenn Linderman wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. They do if you add .lnk to your PATHEXT environment variable. Which is something we probably don't want to do globally. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On Fri, Feb 19, 2010 at 10:39 PM, Glenn Linderman v+pyt...@g.nevcal.comv%2bpyt...@g.nevcal.com wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Windows also has hard-links for files. A lot of Windows tools are completely ignorant of both of those linking concepts... resulting in disks that look to be over capacity when they are not, for example. Virtualenv uses copies when it can't use symlinks. A copy (or hard link) seems appropriate on systems that do not have symlinks. It would seem reasonable that on Windows it might look in the registry to find the actual location where Python was installed. Or... whatever technique Windows people think is best; it's simply necessary that the interpreter know its location (the isolated environment) and also know where Python is installed. All this needs to be calculated in C, as the standard library needs to be on the path very early (so os.symlink wouldn't help, but any C-level function to determine this would be helpful). (It's maybe a bit lame of me that I'm dropping this in the middle of PyCon, as I'm not online frequently during the conference; sorry about that) -- Ian Bicking | http://blog.ianbicking.org | http://twitter.com/ianbicking ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
At 02:41 PM 2/20/2010 -0500, Ian Bicking wrote: Virtualenv uses copies when it can't use symlinks. Â A copy (or hard link) seems appropriate on systems that do not have symlinks. Â It would seem reasonable that on Windows it might look in the registry to find the actual location where Python was installed. Â Or... whatever technique Windows people think is best; it's simply necessary that the interpreter know its location (the isolated environment) and also know where Python is installed. Â All this needs to be calculated in C, as the standard library needs to be on the path very early (so os.symlink wouldn't help, but any C-level function to determine this would be helpful). The ways pretty much boil down to: 1. Explicit per-instance configuration (either appended to the .exe or in a file adjacent to it), 2. An implicit global search/lookup (PATH, registry, etc.) 3. A combination of the two, checking explicit configuration before implicit. Since the virtualenv itself may need some kind of nearby configuration anyway, putting it in that file seems to me like the One Obvious Way To Do It. Windows does have C-level APIs for reading and writing .ini files, from the good old days before the registry existed. And the C-level code might only need to read one entry prior to booting Python anyway - a single call to the GetPrivateProfileString function, once you've determined the name of the file to be read from. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Dj Gilcrease wrote: win2k and later have a form of sym link, the api for it is just not provided in a nice simple app like it is on nix platforms. Yes, it's possible to create symlinks on win2k using a command line tool called 'linkd' (I've done it). However, they're extremely dangerous, because the GUI side of win2k doesn't know about them. It thinks that a symlink to a folder is a real folder, and if you delete it, you end up deleting the contents of the folder that the symlink points to. So if you use them, you need to keep your wits about you. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposal for virtualenv functionality in Python
This is a proto-proposal for including some functionality from virtualenv in Python itself. I'm not entirely confident about what I'm proposing, so it's not really PEP-ready, but I wanted to get feedback... First, a bit about how virtualenv works (this will use Linux conventions; Windows and some Mac installations are slightly different): * Let's say you are creating an environment in ~/env/ * /usr/bin/python is *copied* to ~/env/bin/python * This alone sets sys.prefix to ~/env/ (via existing code in Python) * At this point things are broken because the standard library is not available * virtualenv creates ~/env/lib/pythonX.Y/site.py, which adds the system standard library location (/usr/lib/pythonX.Y) to sys.path * site.py itself requires several modules to work, and each of these modules (from a pre-determined list of modules) is symlinked over from the standard library into ~/env/lib/pythonX.Y/ * site.py may or may not add /usr/lib/pythonX.Y/site-packages to sys.path * *Any* time you use ~/env/bin/python you'll get sys.prefix of ~/env/, and the appropriate path. No environmental variable is required. * No compiler is used; this is a fairly light tool There are some tweaks to this that could be made, but I believe virtualenv basically does things The Right Way. By setting sys.prefix All Tools Work (there are some virtualenv alternatives that do isolation without setting sys.prefix, but they typically break more often than virtualenv, or only support a limited number of workflows). Also by using a distinct interpreter (~/env/bin/python) it works fairly consistently and reliably compared to techniques like an environmental variable. The one serious alternative is what buildout (and virtualenv --relocatable) does, which is to use the system Python and change the path at the beginning of all scripts (it requires its own installer to accomplish this consistently). But virtualenv is kind of a hack, and I believe with a little support from Python this could be avoided. virtualenv can continue to exist to support the equivalent workflows on earlier versions of Python, but it would not exist (or would become much much simpler) on further Python versions. The specific parts of virtualenv that are a hack that I would like to replace with built-in functionality: * I'd rather ~/env/bin/python be a symlink instead of copying it. * I'd rather not copy (or symlink) *any* of the standard library. * I'd rather site.py support this functionality natively (and in turn that OS packagers support this when they make other modifications) * Compiling extensions can be tricky because code may not find headers (because they are installed in /usr, not ~/env/). I think this can be handled better if virtualenv is slightly less intrusive, or distutils is patched, or generally tools are more aware of this layout. * This gets more complicated with a Mac framework build of Python, and hopefully those hacks could go away too. I am not sure what the best way to do this is, but I will offer at least one suggestion (other suggestions welcome): In my (proto-)proposal, a new binary pythonv is created. This is slightly like pythonw.exe, which provides a Python interpreter on Windows which doesn't open a new window. This binary is primarily for creating new environments. It doesn't even need to be on $PATH, so it would be largely invisible to people unless they use it. If you symlink pythonv to a new location, it will effect sys.prefix (currently sys.prefix is calculated after dereferencing the symlink). Additionally, the binary will look for a configuration file. I'm not sure where this file should go; perhaps directly alongside the binary, or in some location based on sys.prefix. The configuration file would be a simple set of assignments; some I might imagine: * Maybe override sys.prefix * Control if the global site-packages is placed on sys.path * On some operating systems there are other locations for packages installed with the system packager; probably these should be possible to enable or disable * Maybe control installations or point to a file like distutils.cfg I got some feedback from the Debian/Ubuntu maintainer that he would like functionality that might be like this; for instance, if you have /usr/bin/python2.6 and /usr/bin/python2.6-dbg, he'd like them to work slightly different (e.g., /usr/bin/python2.6-dbg would look in a different place for libraries). So the configuration file location should be based on sys.prefix *and* the name of the binary itself (e.g., /usr/lib/python2.6/python-config-dbg.conf). I have no strong opinion on the location of the file itself, only that it can be specific to the directory and name of the interpreter. In addition to all this, I think sys would grow another prefixy value, e.g., sys.build_prefix, that points to the place where Python was actually built (virtualenv calls this sys.real_prefix, but that's not a very good name). Some code, especially in distutils, might
Re: [Python-Dev] Proposal for virtualenv functionality in Python
This sounds like a great idea (especially since I proposed something a little bit like it in yesterday's language summit :-). I have to admit I cannot remember what uses are made of sys.prefix; it would be good to explicitly enumerate these in the PEP when you write it. Regarding the Windows question, does virtualenv work on Windows? If so, its approach might be adopted. If not, maybe we shouldn't care (in the first version anyway)? --Guido On Fri, Feb 19, 2010 at 1:49 PM, Ian Bicking i...@colorstudy.com wrote: This is a proto-proposal for including some functionality from virtualenv in Python itself. I'm not entirely confident about what I'm proposing, so it's not really PEP-ready, but I wanted to get feedback... First, a bit about how virtualenv works (this will use Linux conventions; Windows and some Mac installations are slightly different): * Let's say you are creating an environment in ~/env/ * /usr/bin/python is *copied* to ~/env/bin/python * This alone sets sys.prefix to ~/env/ (via existing code in Python) * At this point things are broken because the standard library is not available * virtualenv creates ~/env/lib/pythonX.Y/site.py, which adds the system standard library location (/usr/lib/pythonX.Y) to sys.path * site.py itself requires several modules to work, and each of these modules (from a pre-determined list of modules) is symlinked over from the standard library into ~/env/lib/pythonX.Y/ * site.py may or may not add /usr/lib/pythonX.Y/site-packages to sys.path * *Any* time you use ~/env/bin/python you'll get sys.prefix of ~/env/, and the appropriate path. No environmental variable is required. * No compiler is used; this is a fairly light tool There are some tweaks to this that could be made, but I believe virtualenv basically does things The Right Way. By setting sys.prefix All Tools Work (there are some virtualenv alternatives that do isolation without setting sys.prefix, but they typically break more often than virtualenv, or only support a limited number of workflows). Also by using a distinct interpreter (~/env/bin/python) it works fairly consistently and reliably compared to techniques like an environmental variable. The one serious alternative is what buildout (and virtualenv --relocatable) does, which is to use the system Python and change the path at the beginning of all scripts (it requires its own installer to accomplish this consistently). But virtualenv is kind of a hack, and I believe with a little support from Python this could be avoided. virtualenv can continue to exist to support the equivalent workflows on earlier versions of Python, but it would not exist (or would become much much simpler) on further Python versions. The specific parts of virtualenv that are a hack that I would like to replace with built-in functionality: * I'd rather ~/env/bin/python be a symlink instead of copying it. * I'd rather not copy (or symlink) *any* of the standard library. * I'd rather site.py support this functionality natively (and in turn that OS packagers support this when they make other modifications) * Compiling extensions can be tricky because code may not find headers (because they are installed in /usr, not ~/env/). I think this can be handled better if virtualenv is slightly less intrusive, or distutils is patched, or generally tools are more aware of this layout. * This gets more complicated with a Mac framework build of Python, and hopefully those hacks could go away too. I am not sure what the best way to do this is, but I will offer at least one suggestion (other suggestions welcome): In my (proto-)proposal, a new binary pythonv is created. This is slightly like pythonw.exe, which provides a Python interpreter on Windows which doesn't open a new window. This binary is primarily for creating new environments. It doesn't even need to be on $PATH, so it would be largely invisible to people unless they use it. If you symlink pythonv to a new location, it will effect sys.prefix (currently sys.prefix is calculated after dereferencing the symlink). Additionally, the binary will look for a configuration file. I'm not sure where this file should go; perhaps directly alongside the binary, or in some location based on sys.prefix. The configuration file would be a simple set of assignments; some I might imagine: * Maybe override sys.prefix * Control if the global site-packages is placed on sys.path * On some operating systems there are other locations for packages installed with the system packager; probably these should be possible to enable or disable * Maybe control installations or point to a file like distutils.cfg I got some feedback from the Debian/Ubuntu maintainer that he would like functionality that might be like this; for instance, if you have /usr/bin/python2.6 and /usr/bin/python2.6-dbg, he'd like them to work slightly different (e.g., /usr/bin/python2.6-dbg would look in a different
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Le Fri, 19 Feb 2010 13:49:23 -0500, Ian Bicking a écrit : * I'd rather ~/env/bin/python be a symlink instead of copying it. How about simply adding a --prefix argument to the interpreter. Then virtualenv can create a python script that simply adds --prefix and forwards all the arguments to the real python executable. Or am I missing something? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On Feb 19, 2010, at 11:45 AM, Antoine Pitrou wrote: Le Fri, 19 Feb 2010 13:49:23 -0500, Ian Bicking a écrit : * I'd rather ~/env/bin/python be a symlink instead of copying it. How about simply adding a --prefix argument to the interpreter. Then virtualenv can create a python script that simply adds --prefix and forwards all the arguments to the real python executable. Or am I missing something? It couldn't be a shell script, as they wouldn't work as shebang line interpreters for other python scripts. -- Philip Jenvey ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby p...@telecommunity.com wrote: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) Some recent discussion pointed out that vista and win7 ntfs actually supports symlinks. the same question about determining where it was launched from may still hold there? (and we need this to work on xp). How often do windows users need something like virtualenv? (Asking for experience from windows users of all forms here). I personally can't imagine anyone that would ever use a system generic python install from a .msi unless they're just learning python. I would hope people would already use py2exe or similar and include an entire CPython VM with their app with their own installer but as I really have nothing to do with windows these days I'm sure I'm wrong. What about using virtualenv with ironpython and jython? does it make any sense in that context? how do we make it not impossible for them to support? despite all the questions, I'm +1 on going ahead with a PEP and sprint discussions to figure out how to get it in for CPython 3.2 and 2.7. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
win2k and later have a form of sym link, the api for it is just not provided in a nice simple app like it is on nix platforms. On 2/19/10, P.J. Eby p...@telecommunity.com wrote: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/digitalxero%40gmail.com -- Dj Gilcrease OpenRPG Developer ~~http://www.openrpg.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
I develop OpenRPG and 90% of our user base is on windows. We require the user to install python and wxPython from msi because our app supports GUI plugins so to ensure the user can use any plugin even if it isnt prepackaged they need to have the full python and wxPython installed. We are working on changing the code around to work better with py2exe py2app. But I use virtual env on windows linux to test multiple py/wx combos that our app supports On 2/19/10, Gregory P. Smith g...@krypto.org wrote: On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby p...@telecommunity.com wrote: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) Some recent discussion pointed out that vista and win7 ntfs actually supports symlinks. the same question about determining where it was launched from may still hold there? (and we need this to work on xp). How often do windows users need something like virtualenv? (Asking for experience from windows users of all forms here). I personally can't imagine anyone that would ever use a system generic python install from a .msi unless they're just learning python. I would hope people would already use py2exe or similar and include an entire CPython VM with their app with their own installer but as I really have nothing to do with windows these days I'm sure I'm wrong. What about using virtualenv with ironpython and jython? does it make any sense in that context? how do we make it not impossible for them to support? despite all the questions, I'm +1 on going ahead with a PEP and sprint discussions to figure out how to get it in for CPython 3.2 and 2.7. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/digitalxero%40gmail.com -- Dj Gilcrease OpenRPG Developer ~~http://www.openrpg.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On Fri, 19 Feb 2010 14:35:42 -0700, Dj Gilcrease digitalx...@gmail.com wrote: On 2/19/10, P.J. Eby p...@telecommunity.com wrote: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) win2k and later have a form of sym link, the api for it is just not provided in a nice simple app like it is on nix platforms. See also http://bugs.python.org/issue1578269, which proposes an implementation of os.symlink for windows, and appears to be just about ready to go in. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On 19/02/2010 16:30, Gregory P. Smith wrote: On Fri, Feb 19, 2010 at 4:18 PM, P.J. Ebyp...@telecommunity.com wrote: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) Some recent discussion pointed out that vista and win7 ntfs actually supports symlinks. the same question about determining where it was launched from may still hold there? (and we need this to work on xp). How often do windows users need something like virtualenv? (Asking for experience from windows users of all forms here). I personally can't imagine anyone that would ever use a system generic python install from a .msi unless they're just learning python. I would hope people would already use py2exe or similar and include an entire CPython VM with their app with their own installer but as I really have nothing to do with windows these days I'm sure I'm wrong. I've used virtualenv on Windows and it is just as useful as on other platforms. *Most* Python developers I know work from an installed Python although application distribution is typically done with py2exe. The Windows msi installer is downloaded an insane amount from Python.org. Michael What about using virtualenv with ironpython and jython? does it make any sense in that context? how do we make it not impossible for them to support? despite all the questions, I'm +1 on going ahead with a PEP and sprint discussions to figure out how to get it in for CPython 3.2 and 2.7. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Windows also has hard-links for files. A lot of Windows tools are completely ignorant of both of those linking concepts... resulting in disks that look to be over capacity when they are not, for example. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Glenn Linderman wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On approximately 2/19/2010 7:52 PM, came the following characters from the keyboard of Eric Smith: Glenn Linderman wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. So if you can't test it, why would you state it as a fact... and then back-pedal? :) Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. d:\python.exe Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. exit() d:\c:\python26\python.exe ActivePython 2.6.2.2 (ActiveState Software Inc.) based on Python 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. exit() d:\d:\python.exe.lnk d:\ActivePython 2.6.2.2 (ActiveState Software Inc.) based on Python 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. So this makes it look like it works fine. But doing exit() from the shortcut-started python fails... it hangs, eventually the whole CMD shell dies, if you poke it enough. I'm going to let it sit there a long time ... until I shut down, and see if it ever exits properly. The form d:\start python.exe.lnk gives the python its own window, and that works/exits fine. So, shortcuts do work from the shell, but there might be some issues, and you might have to type the .lnk to invoke them (I haven't played with adding .lnk or .exe.lnk to PATHEXT) I don't have a clue if the above problem is a Windows issue, or a Python issue. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
-- http://www.ironpythoninaction.com On 19 Feb 2010, at 22:52, Eric Smith e...@trueblade.com wrote: Glenn Linderman wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. They do if you add .lnk to your PATHEXT environment variable. Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
