[issue15307] Patch for --symlink support in pyvenv with framework python

Roundup Robot added the comment: New changeset 4610ac42130e by Ned Deily in branch 'default': Issue #15678: Fix menu customization for IDLE started from OS X http://hg.python.org/cpython/rev/4610ac42130e -- ___ Python tracker

[issue15307] Patch for --symlink support in pyvenv with framework python

Ronald Oussoren added the comment: There is no NEWS entry, I'll commit one when I get home. -- ___ Python tracker ___ ___ Python-bugs

[issue15307] Patch for --symlink support in pyvenv with framework python

Roundup Robot added the comment: New changeset b79d276041a8 by Vinay Sajip in branch 'default': Closes #15307: symlinks now work on OS X with framework Python builds. Patch by Ronald Oussoren. http://hg.python.org/cpython/rev/b79d276041a8 -- resolution: -> fixed stage: commit review

[issue15307] Patch for --symlink support in pyvenv with framework python

Ned Deily added the comment: v7 looks good to me -- stage: -> commit review ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue15307] Patch for --symlink support in pyvenv with framework python

Ronald Oussoren added the comment: And a final update: don't use TAB characters -- Added file: http://bugs.python.org/file26398/venv-symlinks-v7.txt ___ Python tracker ___ _

[issue15307] Patch for --symlink support in pyvenv with framework python

Ronald Oussoren added the comment: The test failure in test_osx_env is in itself fairly harmless because PYTHONEXECUTABLE is only used to ensure IDLE.app works correct, and IDLE.app doesn't use the pythonw executable and hence won't hit the code that special-cases the venv location. That sai

[issue15307] Patch for --symlink support in pyvenv with framework python

Roundup Robot added the comment: New changeset f954ee489896 by Vinay Sajip in branch 'default': Issue #15307: Skipped test_venv:test_prefixes when run from a venv. http://hg.python.org/cpython/rev/f954ee489896 -- nosy: +python-dev ___ Python tracker

[issue15307] Patch for --symlink support in pyvenv with framework python

Ned Deily added the comment: v5 fixes the non normalized path issue. However, the PYTHONEXECUTABLE env var -> argv processing is still broken, as detected by the test_osx_env failure. It's definitely caused by interaction between pythonw.c and the main interpreter; if the interpreter is lau

[issue15307] Patch for --symlink support in pyvenv with framework python

Vinay Sajip added the comment: As the test is constructed now, that test will fail if run from a venv. It will be a simple matter to skip it if test_venv being run from a venv - I can add that at some point, but I agree it's orthogonal to the crux of this issue. -- __

[issue15307] Patch for --symlink support in pyvenv with framework python

Ned Deily added the comment: That's correct, the failing test was being run from a venv. I see now that what had changed is that the fixes for Issue15241 recently added the test_prefixes test case to test_venv and that fails when the test is run from within a venv. Without that new test cas

[issue15307] Patch for --symlink support in pyvenv with framework python

Ronald Oussoren added the comment: Ned mentioned that test_venv fails on line 95 when you run test_venv *in* a virtualenv, that is: $ pyvenv testenv $ testenv/bin/python3 -m test.test_venv This fails because sys.prefix != sys.base_prefix for testenv/bin/python3, and that's expected. Unless

[issue15307] Patch for --symlink support in pyvenv with framework python

Vinay Sajip added the comment: > In particular line 95 of test_venv explicitly tests that > sys.prefix == sys.base_prefix, which should fail when running the > test within a virtual env. Tweaking the test suite to avoid that > failure is beyond the scope of this issue. The first part of the tes

[issue15307] Patch for --symlink support in pyvenv with framework python

Ronald Oussoren added the comment: v5 adds test cases for sys.executable and calls realpath on dirname(argv[0]) in pythonw.c and also has the changes in Ned's v4. The test failure for test_venv is expected, the note in explains that "sys.base_pre

[issue15307] Patch for --symlink support in pyvenv with framework python

Ronald Oussoren added the comment: I removed the call to realpath from pythonw because resolving symlinks breaks the feature. Realpath also converts relative paths to absolute paths, and that probably explains the new failure you're having. I'll try to find a solution for this, possibly by ca

[issue15307] Patch for --symlink support in pyvenv with framework python

Ned Deily added the comment: Fixing sys.executable to point to the stub launcher instead of the interpreter in the fw will also fix other unrelated issues, like making python3-32 work properly in 64-/32-bit builds for IDLE and for tests that spawn interpreters in subprocesses. Today, while t

[issue15307] Patch for --symlink support in pyvenv with framework python

Ronald Oussoren added the comment: based on code inspection I'd say that sys.executable was broken without my patch as well. The code that sets that value is unchanged from Python 3.2, and that points to the executable inside the Python.app application bundle. I've attached v3 of my patch, th

[issue15307] Patch for --symlink support in pyvenv with framework python

Ronald Oussoren added the comment: I've attached a new version of the patch: * copy to tmp buffer instead of argv0_buffer (see comment by Ned) * add include in pythonw.c to avoid compiler warning * use _Py_char2wchar instead of blindly casting a char* to a wchar_t* The behavior is not perfe

[issue15307] Patch for --symlink support in pyvenv with framework python

Ronald Oussoren added the comment: The current code works, and I don't understand why it does. I'd love to get rid of the long deprecated APIs like NSModuleForSymbol as well, but we'll have to ask the RM if that is an acceptable change at this point in the 3.3 release process. BTW. Is adding

[issue15307] Patch for --symlink support in pyvenv with framework python

Ned Deily added the comment: I think you're right that the casts are incorrect. I think the existing cast ia a day one bug in Python 3. The question is why hasn't it been a problem? That area needs fixing up since NSModuleForSymbol, NSLookupAndBindSymbol, and NSLibraryNameForModule are now

[issue15307] Patch for --symlink support in pyvenv with framework python

Changes by Ronald Oussoren : -- nosy: +ned.deily, vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue15307] Patch for --symlink support in pyvenv with framework python

New submission from Ronald Oussoren : 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 t