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 wrote:

On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory P. Smith wrote:

On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby 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,

At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: 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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----

-----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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----

On Fri, 19 Feb 2010 14:35:42 -0700, Dj Gilcrease wrote:

On 2/19/10, P.J. Eby 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

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

-- http://www.ironpythoninaction.com On 19 Feb 2010, at 22:52, Eric Smith wrote:

Glenn Linderman 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.) No automatic way, but shortcuts can include parameters, not just

On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: 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.u...

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

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

On Fri, Feb 19, 2010 at 10:39 PM, 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.

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