On 19 Jul, 2011, at 13:52, Vinay Sajip wrote: > Ronald Oussoren <ronaldoussoren <at> mac.com> writes: > >> I'm not sure if I like this approach, I'll read the PEP before I start > discussing that though. One thing I want >> to mention beforehand: why is the file named 'env.cfg' instead of something > starting with 'py'? The >> latter is basicly namespacing the filename and avoids clashes with other > software (although I don't know >> of any software that uses an env.cfg file). > > Thanks for your feedback. > > This file will only appear in the root folder of a virtual environment (i.e. > the > prefix location), so it's pretty unlikely to cause a clash in practice. > However, > the name change is easy to make at any point before release. > > What is it that you don't like about the proposed approach?
I'll read the PEP before responding to this question. > >> This should work fine with a framework build, with two caveats: >> >> 1) bin/python in a framework build is not the interpreter, but a stub > executable. The script that creates >> the virtual environment should copy the executable in > Resources/Python.app/MacOS instead. >> bin/python just execv-s the real interpreter. >> >> 2) accessing GUI functionality requires that the executable is located in an > .app bundle, that's why >> bin/python is a stub. >> >> The latter point means that virualenvs will be slightly less functional than > the framework install there >> based on unless you add more OSX specific code. It should be fairly easy to > get this to work though, basicly >> create a Python.app in a hidden folder in the virtualenv and copy the real > interpreter into that, then add a >> bin/python that execv's that hidden Python.app. > > That raises a few more questions :-) > > 1. Since we only use a copy of the executable so that argv[0] (and hence > sys.executable) will point to the environment (and hence allow locating the > environment config), mightn't the fact that a stub is used work to our > advantage, in that it doesn't take up much disk space? The 'env.cfg' file will be next to the stub executable, and hence not in a location where the real interpreter will look. > 2. How does the stub locate the real executable? The stub is linked to the framework and uses that to find the sys.prefix, the real executable is located in a fixed location relative to sys.prefix. That's one other difference w.r.t. regular builds: framework builds use the location of the shared library to calculate sys.prefix. AFAIK this functionality was inherited from the NextStep port. > 3. What would the minimum contents of the Python.app folder be? With some luck only Python.app/Contents/MacOS/Python needs to be present (the real executable), but it would be better to include the Info.plist file as well because some gui frameworks use the contents of that file > 4. Does PyObjC support Python 3 yet? There's no mention of it on the PyObjC > site, and from what I can tell this would need to be functional before Cocoa > GUIs could be programmed in Python 3. PyObjC supports Python 3, the site is very much out of date. I haven't found time to redesign the site yet, which needs to be done because the maintanence scripts no longer work due to some code reorganisations in PyObjC itself. Ronald > > Regards, > > Vinay Sajip > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG