Re: [Python-Dev] Existence of pythonNN.zip in sys.path
On 5/6/2014 1:14 PM, Terry Reedy wrote: > On 5/5/2014 5:32 PM, Anthony Tuininga wrote: >> Hi, >> >> I am the author of cx_Freeze which creates "frozen" executables from >> Python scripts. To this point I have been using frozen modules (compiled >> C) but this has the side effect of bundling parts of Python with a >> cx_Freeze release -- and this has bitten me on a number of occasions >> when newer versions of Python use slightly incompatible modules. :-) >> >> By scanning the code I discovered that Python automatically searches on >> startup >> >> /lib/pythonNN.zip >> >> where NN is replaced by the major and minor version that is being >> executed. Using this would allow me to ensure that bootstrap modules are >> not bundled with cx_Freeze but acquired from the distribution that is >> actually using it -- thereby eliminating the hassle noted above. >> >> I have tested this approach and found it works flawlessly. There is, >> however, no documentation that I can find for the contents of sys.path >> -- the documentation simply says that it is an installation default and >> doesn't specify what that default is. >> >> So my question is: can I safely make use of this "feature"? It has >> remained in place since at least Python 2.6 but I don't want to assume >> anything. Please advise! Thanks. > > I would say yes. AFAIK /lib has always by used for the stdlib on Windows > and /lib/pythonxy on *nix. Both are mentioned in the 4th paragraph of > the site module doc. We do not lightly change directory structure. PEP > 273 then says "The zip archive must be treated exactly as a subdirectory > tree,". I take this to mean that lib/pythonxy.zip should work the same > as lib/pythonxy/ does. > > You can depend on the feature working as long as it works. Your bigger > worry is accidental regression. I suggest testing release candidates > (there is one for 3.4.1 now, I believe) and also an early alpha and beta > for new release. The candidate may have a zip patch affecting central > directory reading. If not, there is an issue on the tracker. You could > monitor patches by filtering the new-issue announcements for 'zip'. The best course of action would be to integrate any such tests into the stdlib test suite, where a regression would immediately be detected. Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Existence of pythonNN.zip in sys.path
On 5/7/2014 7:45 AM, Eric V. Smith wrote: On 5/6/2014 1:14 PM, Terry Reedy wrote: On 5/5/2014 5:32 PM, Anthony Tuininga wrote: Hi, I am the author of cx_Freeze which creates "frozen" executables from Python scripts. To this point I have been using frozen modules (compiled C) but this has the side effect of bundling parts of Python with a cx_Freeze release -- and this has bitten me on a number of occasions when newer versions of Python use slightly incompatible modules. :-) By scanning the code I discovered that Python automatically searches on startup /lib/pythonNN.zip where NN is replaced by the major and minor version that is being executed. Using this would allow me to ensure that bootstrap modules are not bundled with cx_Freeze but acquired from the distribution that is actually using it -- thereby eliminating the hassle noted above. I have tested this approach and found it works flawlessly. There is, however, no documentation that I can find for the contents of sys.path -- the documentation simply says that it is an installation default and doesn't specify what that default is. So my question is: can I safely make use of this "feature"? It has remained in place since at least Python 2.6 but I don't want to assume anything. Please advise! Thanks. I would say yes. AFAIK /lib has always by used for the stdlib on Windows and /lib/pythonxy on *nix. Both are mentioned in the 4th paragraph of the site module doc. We do not lightly change directory structure. PEP 273 then says "The zip archive must be treated exactly as a subdirectory tree,". I take this to mean that lib/pythonxy.zip should work the same as lib/pythonxy/ does. You can depend on the feature working as long as it works. Your bigger worry is accidental regression. I suggest testing release candidates (there is one for 3.4.1 now, I believe) and also an early alpha and beta for new release. The candidate may have a zip patch affecting central directory reading. If not, there is an issue on the tracker. You could monitor patches by filtering the new-issue announcements for 'zip'. The best course of action would be to integrate any such tests into the stdlib test suite, where a regression would immediately be detected. We do not and should not put tests of 3rd party products that we do not distribute ourselves into the stdlib test suite. Anthony should test *his* pythonxy.dll himself. To the extent feasible, we should test the promised behavior of python.exe regardless of what any 3rd party developer does. If pythonxy.zip supplements rather than replacing pythonxy/*.py, this should be easy enough: copy .zip into place, run python in a subprocess, check the result, delete .zip. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Existence of pythonNN.zip in sys.path
On 05/07/2014 01:13 PM, Terry Reedy wrote: > On 5/7/2014 7:45 AM, Eric V. Smith wrote: >> On 5/6/2014 1:14 PM, Terry Reedy wrote: >>> On 5/5/2014 5:32 PM, Anthony Tuininga wrote: Hi, I am the author of cx_Freeze which creates "frozen" executables from Python scripts. To this point I have been using frozen modules (compiled C) but this has the side effect of bundling parts of Python with a cx_Freeze release -- and this has bitten me on a number of occasions when newer versions of Python use slightly incompatible modules. :-) By scanning the code I discovered that Python automatically searches on startup /lib/pythonNN.zip where NN is replaced by the major and minor version that is being executed. Using this would allow me to ensure that bootstrap modules are not bundled with cx_Freeze but acquired from the distribution that is actually using it -- thereby eliminating the hassle noted above. I have tested this approach and found it works flawlessly. There is, however, no documentation that I can find for the contents of sys.path -- the documentation simply says that it is an installation default and doesn't specify what that default is. So my question is: can I safely make use of this "feature"? It has remained in place since at least Python 2.6 but I don't want to assume anything. Please advise! Thanks. >>> >>> I would say yes. AFAIK /lib has always by used for the stdlib on Windows >>> and /lib/pythonxy on *nix. Both are mentioned in the 4th paragraph of >>> the site module doc. We do not lightly change directory structure. PEP >>> 273 then says "The zip archive must be treated exactly as a subdirectory >>> tree,". I take this to mean that lib/pythonxy.zip should work the same >>> as lib/pythonxy/ does. >>> >>> You can depend on the feature working as long as it works. Your bigger >>> worry is accidental regression. I suggest testing release candidates >>> (there is one for 3.4.1 now, I believe) and also an early alpha and beta >>> for new release. The candidate may have a zip patch affecting central >>> directory reading. If not, there is an issue on the tracker. You could >>> monitor patches by filtering the new-issue announcements for 'zip'. >> >> The best course of action would be to integrate any such tests into the >> stdlib test suite, where a regression would immediately be detected. > > We do not and should not put tests of 3rd party products that we do not > distribute ourselves into the stdlib test suite. Anthony should test > *his* pythonxy.dll himself. To the extent feasible, we should test the > promised behavior of python.exe regardless of what any 3rd party > developer does. > > If pythonxy.zip supplements rather than replacing pythonxy/*.py, this > should be easy enough: copy .zip into place, run python in a subprocess, > check the result, delete .zip. I'm sorry, I misread this. I thought the question was about putting the stdlib itself in pythonxy.zip. I agree we shouldn't test someone else using that filename. Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
