Patchwork [STABLE] ignore python folder included within hackable hg packages

login
register
mail settings
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

Steve Borho - Sept. 9, 2014, 6:44 p.m.
# 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.

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.
hgpatchbot@gmail.com - Sept. 9, 2014, 6:57 p.m.
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)
Adrian Buehlmann - Sept. 9, 2014, 7:15 p.m.
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?
Steve Borho - Sept. 9, 2014, 8:45 p.m.
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.
Adrian Buehlmann - Sept. 9, 2014, 9:19 p.m.
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..)
Mads Kiilerich - Sept. 10, 2014, 12:02 a.m.
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$
Adrian Buehlmann - Sept. 10, 2014, 7:27 a.m.
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.
Steve Borho - Sept. 10, 2014, 8:38 a.m.
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$