[PATCH 2 of 2 v3] makefile: add wheel build target

[Nathan Goldbaum]

On Mon, Oct 12, 2015 at 11:01 PM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

>
>
> On Mon, Oct 12, 2015 at 10:36 PM, Gregory Szorc <gregory.szorc at gmail.com>
> wrote:
>
>> On Mon, Oct 12, 2015 at 11:42 AM, Gregory Szorc <gregory.szorc at gmail.com>
>> wrote:
>>
>>> On Mon, Oct 12, 2015 at 7:39 AM, Augie Fackler <raf at durin42.com> wrote:
>>>
>>>> On Fri, Oct 09, 2015 at 12:31:16PM -0500, Nathan Goldbaum wrote:
>>>> > # HG changeset patch
>>>> > # User Nathan Goldbaum <ngoldbau at ucsc.edu>
>>>> > # Date 1444411846 18000
>>>> > #      Fri Oct 09 12:30:46 2015 -0500
>>>> > # Node ID c630785461f0465adebce581eb25a503f654333a
>>>> > # Parent  d27f31183f4ca4af2a0a96af32a631181b501b5a
>>>> > makefile: add wheel build target
>>>>
>>>> Queued. How well does the wheel work on Windows?
>>>>
>>>
>>> When I attempted this several months ago, I think it "just worked."
>>> However, I'm not sure hg.exe was produced. However, if you are installing
>>> Mercurial via wheels/pip on Windows, chances are you have a UNIX-like env
>>> (such as cygwin) and don't need the .exe wrapper.
>>>
>>> I can probably find time to investigate this on my Windows machine this
>>> week if there is any interest in producing wheels as part of the 3.6
>>> release.
>>>
>>
>> `python.exe setup.py bdist_wheel` seems to produce a correct wheel,
>> compiled C extensions .pyd files and all! I did a `pip.exe install
>> mercurial-3.5.2-cp27-none-win_amd64.whl` into a virtualenv and it seemed to
>> "just work." `hg debuginstall` was happy. `hg serve` has access to
>> templates.
>>
>> The one thing that isn't in the wheel is a hg.exe. But there is a hg.bat,
>> which is sufficient for `hg` to work in cmd.exe. As I mentioned in my
>> previous message, if you are installing a wheel, you probably have a
>> "proper" Python environment and don't need the standalone / Python-bundled
>> Mercurial that hg.exe/py2exe provides. So I don't think this is a problem.
>>
>> Another issue might be the file naming. Even though I built @, the
>> filename and version metadata inside the wheel was "3.5.2" and didn't have
>> the "+N" component that we put in `hg --version`. Not sure if this is a bug
>> or by design.
>>
>
> This may be related to pep-0440:
> https://www.dropbox.com/sh/onqhazd6nryy6n5/AADNJhY2l1Omh15aMDbgEeWha?dl=0
>

Sorry about this, I used the wrong URL here.
https://www.python.org/dev/peps/pep-0440/


>
>
>>
>> I performed a `python.exe setup.py bdist_egg` and compared the resulting
>> zip archives. The content was exactly the same except a) the egg had an
>> EGG-INFO directory b) the wheel had mercurial-3.5.2.data and
>> mercurial-3.5.2.dist-info directory c) the egg had .pyc files. The .pyc
>> files made the egg ~2.6 MB instead of ~1.3 MB for the wheel. I /thought/
>> wheel files contained .pyc files. But I must be wrong or it isn't relevant
>> because `pip.exe install` appeared to create the .pyc files automagically.
>>
>> I'm not a wheel expert and there might be some issues with the low-level
>> wheel metadata (content of mercurial-<version>.dist-info directory) but
>> AFAICT the produced .whl file looks like a valid, working Mercurial
>> distribution! I dare say "it just works."
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151012/86f1b540/attachment.html>