Submitter | Steve Borho |
---|---|
Date | Sept. 9, 2014, 6:44 p.m. |
Message ID | <9287bf0cdcc890e63f9a.1410288269@zeppelin.fritz.box> |
Download | mbox | patch |
Permalink | /patch/5755/ |
State | Changes Requested |
Headers | show |
Comments
Dear Contributor, check-commit <http://selenic.com/repo/hg/file/default/contrib/check-commit> found the following errors with this patch: 7: summary line doesn't start with 'topic: ' ignore python folder included within hackable hg packages (see ContributingChanges <http://mercurial.selenic.com/wiki/ContributingChanges> for more info, this is an automated message)
On 2014-09-09 20:44, Steve Borho wrote:
> the hg-python/ path is only checked when PYTHONHOME is found in the environment,
Are you sure?
On 09/09, Adrian Buehlmann wrote: > On 2014-09-09 20:44, Steve Borho wrote: > > the hg-python/ path is only checked when PYTHONHOME is found in the environment, > > Are you sure? Ahh. GetEnvironmentVariable returns 0 on failure. I should not have guessed. While I have your attention, why is PYTHONHOME considered in this function at all, if its contents are ignored? Please explain how this was intended to work.
On 2014-09-09 22:45, Steve Borho wrote: > On 09/09, Adrian Buehlmann wrote: >> On 2014-09-09 20:44, Steve Borho wrote: >>> the hg-python/ path is only checked when PYTHONHOME is found in the environment, >> >> Are you sure? > > Ahh. GetEnvironmentVariable returns 0 on failure. I should not have guessed. > > While I have your attention, why is PYTHONHOME considered in this > function at all, if its contents are ignored? Please explain how this > was intended to work. > It's been too long since I hacked on that stuff to really remember, but I think that the python interpreter (call of Py_Main in exewrapper.c) will interpret PYTHONHOME if it is set and I think the idea was that it doesn't make sense to interfere with that, iff PYTHONHOME is set. After all, if somebody sets PYTHONHOME then she probably knows where the python libs are. Perhaps setting PYTHONHOME was used on the buildbot [1] or something like that. I can't remember any more. [1] http://mercurial.selenic.com/wiki/Buildbot (which looks down-ish..)
On 09/09/2014 08:44 PM, Steve Borho wrote: > # HG changeset patch > # User Steve Borho <steve@borho.org> > # Date 1410288246 -7200 > # Tue Sep 09 20:44:06 2014 +0200 > # Branch stable > # Node ID 9287bf0cdcc890e63f9a596f9e335a9b72a9532c > # Parent 71227dc24311b6d83904c50bacf7b339b1454bec > ignore python folder included within hackable hg packages > > the exewrapper.c that builds hg.exe for the hackable hg packages allows two > names for the Python install folder, hg-python or python2N where N matches the > minor version of Python you compiled against. Where / how do the python2N/ stuff happen? Have you tried it? AFAIK it has a mechanism for loading python2x.dll from $PATH but no direct alternative to hg-python. I have a vague recollection that the exewrapper search for hg-python only works if the hg.exe is invoked with a path (or in same directory) - it doesn't work to place the hackable directory with hg.exe in $PATH. Running the tests on windows thus broke and required another hack ... and that turned out to be to install a global python with the dlls in $PATH and not use hackable at all, or perhaps just to set $PYTHONHOME. /Mads > the hg-python/ path is only checked when PYTHONHOME is found in the environment, > for reasons that are just beyond my comprehension. So it is easier for me to > just use python27/ for my hackable-hg packages but this path is not yet ignored. > > diff -r 71227dc24311 -r 9287bf0cdcc8 .hgignore > --- a/.hgignore Tue Sep 02 03:41:01 2014 +0200 > +++ b/.hgignore Tue Sep 09 20:44:06 2014 +0200 > @@ -59,5 +59,6 @@ > ^\.(pydev)?project > > # hackable windows distribution additions > +^python2? > ^hg-python > ^hg.py$
On 2014-09-10 02:02, Mads Kiilerich wrote: > Running the tests on windows thus broke and required another hack ... > and that turned out to be to install a global python with the dlls in > $PATH and not use hackable at all, (...) I think that claim is wrong.
On 09/10, Mads Kiilerich wrote: > On 09/09/2014 08:44 PM, Steve Borho wrote: > ># HG changeset patch > ># User Steve Borho <steve@borho.org> > ># Date 1410288246 -7200 > ># Tue Sep 09 20:44:06 2014 +0200 > ># Branch stable > ># Node ID 9287bf0cdcc890e63f9a596f9e335a9b72a9532c > ># Parent 71227dc24311b6d83904c50bacf7b339b1454bec > >ignore python folder included within hackable hg packages > > > >the exewrapper.c that builds hg.exe for the hackable hg packages allows two > >names for the Python install folder, hg-python or python2N where N matches the > >minor version of Python you compiled against. > > Where / how do the python2N/ stuff happen? Have you tried it? AFAIK it has a > mechanism for loading python2x.dll from $PATH but no direct alternative to > hg-python. > > I have a vague recollection that the exewrapper search for hg-python only > works if the hg.exe is invoked with a path (or in same directory) - it > doesn't work to place the hackable directory with hg.exe in $PATH. Running > the tests on windows thus broke and required another hack ... and that > turned out to be to install a global python with the dlls in $PATH and not > use hackable at all, or perhaps just to set $PYTHONHOME. Yeah, I think after staring at exewrapper for a while longer I can see how it is supposed to work. It expects an hg-python/ folder in the same directory as hg.exe and it will try to load pythonXX.dll from that folder based on the version of python which hg.exe was compiled against. Unless PYTHONHOME is set, in which case it just prays pythonXX.dll is in the PATH. This only work if the Python install you've copied into the hackable folder was installed "for you only" otherwise pythonXX.dll is installed in the system folders. Which is what has been tripping me up and making this all work backwards. So you would need to leave hg.exe in the same location as hg-python/ for it to work. To run the tests you would need to do something like: cd tests ../hg-python/python.exe run-tests.py run-tests.py tries to build the extensions, which is annoying, so with my bundle you have to run it from a VC9 x86 shell with DISTUTILS_USE_SDK=1 please ignore this patch.
Patch
diff -r 71227dc24311 -r 9287bf0cdcc8 .hgignore --- a/.hgignore Tue Sep 02 03:41:01 2014 +0200 +++ b/.hgignore Tue Sep 09 20:44:06 2014 +0200 @@ -59,5 +59,6 @@ ^\.(pydev)?project # hackable windows distribution additions +^python2? ^hg-python ^hg.py$