This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ronaldoussoren
Recipients ronaldoussoren
Date 2012-07-09.15:13:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
In-reply-to
Content
The attached patch ensures that "python3.3 -mvenv --symlinks myenv" works with framework builds.

There are two functional changes:
1) don't call 'realpath' in pythonw.c because realpath resolves
   symlinks and that breaks the '--symlinks' options because the
   python command is a symlink with that option (and resolving that
   gives the path to the python executable in the framework)

2) Look for the __PYVENV_LAUNCHER__ environment variable in
   Modules/getpath.c and use that in preference on the already
   calculated value of argv0_path. That code is only active for
   framework builds

I'm not happy with the following line in this patch:

+            wcsncpy(argv0_path, (wchar_t*)pyvenv_launcher, MAXPATHLEN);

That mirrors a similar cast of the result of NSLibraryNameForModule earlier in Modules/getpath.c, but in both cases the input stream is a narrow character string ("char", not "wchar_t") and wcsncpy expects a "wchar_t". The the cast seems to paper over a real problem here.

Shouldn't both lines use "_Py_char2wchar" to convert the char* buffer to a wchar_t* one?
History
Date User Action Args
2012-07-09 15:13:41ronaldoussorensetrecipients: + ronaldoussoren
2012-07-09 15:13:41ronaldoussorensetmessageid: <1341846821.48.0.167902068293.issue15307@psf.upfronthosting.co.za>
2012-07-09 15:13:40ronaldoussorenlinkissue15307 messages
2012-07-09 15:13:40ronaldoussorencreate