[PATCH] py3: write out hgextindex as bytes in setup.py

Matt Harbison mharbison72 at gmail.com
Fri Apr 5 23:25:28 EDT 2019


On Fri, 05 Apr 2019 18:59:42 -0400, Gregory Szorc  
<gregory.szorc at gmail.com> wrote:

>
> The source transforming module importer is going to be “fun” to get  
> working for py2exe. That’s because I believe py2exe is performing its  
> own pyc compilation so the zip has only pyc files. I have doubts that  
> the module compilation includes our custom source transformer. But I  
> could be wrong.
>
> We have a few paths forward...
>
> a) coerce py2exe to work with our custom module importer. This entails  
> either compiling transformed source into bytecode and teaching our  
> importer to load it from the zip file. Or putting .py files in the zip  
> and making our module importer work with that.
>
> b) get rid of the source transforming module importer. (I was kinda  
> hoping we’d be going down this path already. But doing so entails b’’  
> everywhere and we were ratholing in mass rewriting the repo.)
>
> c) give up on py2exe and use PyOxidizer. (I’m still hacking on this,  
> albeit slowly.) PyOxidizer is superior because it is faster and will be  
> a self-contained binary. Mercurial is very much my main test case for  
> PyOxidizer and I’ll add features to PyOxidizer to make it work with  
> Mercurial.

OK, thanks.  I didn't know anything about PyOxidizer- it sounds promising!

I'll probably leave py2exe alone then, as that's well beyond my level of  
knowledge and it sounds like it's more hassle than it's worth.  I was kind  
of interested in how easily it would integrate into the TortoiseHG build-  
I don't have the custom PyQt build that works with py2, so I thought maybe  
working through the py3 issues would provide a platform to test packaging  
changes.

Additionally, it errors out on my laptop when installing the wheel:

C:\Program Files (x86)\Microsoft Visual  
Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\binHostX64\x64\cl.exe  
/c /nologo /Ox /MD /W3 /GS- /DNDEBUG -DPYTHONDLL=\"PYTHON27.DLL\"  
-DPYTHONCOM=\"pythoncom27.dll\" -IC:\Python27\include  
-IC:\Users\Matt\hg\build\venv-inno-x64\PC /Tcsource/start.c  
/Fobuild\temp.win-amd64-2.7\Release\source/start.obj start.c
C:\Program Files (x86)\Windows  
Kits\10\include\10.0.17763.0\ucrt\stdio.h(1933): warning C4005:  
'snprintf': macro redefinition
c:\users\matt\hg\build\py2exe-0.6.9\source\Python-dynload.h(30): note: see  
previous definition of 'snprintf'
C:\Program Files (x86)\Windows  
Kits\10\include\10.0.17763.0\ucrt\stdio.h(1935): fatal error C1189:  
#error:  Macro definition of snprintf conflicts with Standard Library  
function declaration
error: command 'C:\\Program Files (x86)\\Microsoft Visual  
Studio\\2017\\Professional\\VC\\Tools\\MSVC\\14.16.27023\\bin\\HostX64\\x64\\cl.exe'  
failed with exit status 2

It built successfully at work earlier today, so I'm not sure what the  
difference is here- possibly the SDK version?


More information about the Mercurial-devel mailing list