[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