Log file Viewer

[15:19:14] <ngoldbaum> hi all, is this an appropriate place to ask questions about wheels?

[15:19:35] <dstufft> ngoldbaum: sure

[15:19:57] <ngoldbaum> in particular, i'm trying to make it so mercurial's setup.py will produce a wheel, because why not? :)

[15:20:26] <ngoldbaum> i think i have it working, but I'm not able to find the built wheel after running setup.py bdist_wheel

[15:20:31] <ngoldbaum> i'd like to see if it actually works

[15:20:35] <dstufft> ngoldbaum: it should be in dist/

[15:20:51] <ngoldbaum> ah, indeed, there it is!

[15:20:51] <dstufft> unless y'all are doing something strange in your setup.py

[15:20:58] <ngoldbaum> mercurial-3.5.2_654_a024e2db4553_20151009-cp27-none-macosx_10_10_x86_64.whl

[15:21:20] <ngoldbaum> thanks donald!

[15:21:33] <dstufft> ngoldbaum: fwiw you can publish wheels for OSX and Windows (since you have compiled code in Mercurial IIRC) and then Mercurial can install from PyPI without a compiler, we don't yet allow Linux or other OSs to have wheels

[15:21:47] <ngoldbaum> right, was just about to ask about that

[15:22:01] <ngoldbaum> i know that the name of the wheel determines which OSX versions the wheel is installable on (for example)

[15:22:07] <ngoldbaum> where is that documented?

[15:22:22] <ngoldbaum> or do we need buildbots for 10.6 and newer, or something like that?

[15:22:28] <dstufft> ngoldbaum: it's not actually the OSX version, but rather the SDK version

[15:22:49] <ngoldbaum> ah, so if the buildbot has the 10.6 SDK, it'll be installable on all newer versions?

[15:22:51] <dstufft> https://github.com/MacPython/wiki/wiki/Spinning-wheels has a ton of info about it

[15:22:54] <dstufft> ngoldbaum: yes

[15:22:59] <ngoldbaum> same for windows?

[15:23:48] <dstufft> for Windows you need to build it with the right compiler for that CPython version, but otherwise building it on say Win 7 should work on Win 8 (or w/e)

[15:25:01] <ngoldbaum> dstufft: awesome, thanks so much for being so helpful, I know full well that helping people on IRC is pretty thankless

[15:25:49] <dstufft> ngoldbaum: no problem :)

[15:26:18] <dstufft> ngoldbaum: I *think* if you don't have any requirements on a particular SDK, that building a wheel with Python.org installed Python on any version of OSX is your best bet for compatability

[15:26:36] <dstufft> (IDK if you link to CommonCrypto or anything where you don't support older SDKs)

[15:27:07] <ngoldbaum> i believe mercurial only uses the crypto libs in the standard library

[15:27:25] <ngoldbaum> (might be wrong about that)

[15:27:36] <dstufft> Most likely

[16:10:56] <ngoldbaum> dstufft: so it looks like mercurial won't be happy with setuptools anytime soon...

[16:10:59] <ngoldbaum> https://selenic.com/pipermail/mercurial-devel/2015-February/066236.html and replies

[16:11:41] <ngoldbaum> i'm no expert, maybe there's a way to make it not do egg-like installs? This seems to horribly break lots of things.

[16:13:47] <dstufft> how is it installing stuff

[16:13:52] <dstufft> is it ``setup.py install``

[16:14:55] <ngoldbaum> setup.py build, looks like

[16:15:15] <ngoldbaum> i'm not sure how exactly the makefile is invoked for the various platform packages

[16:15:51] <ngoldbaum> ah, make install is doing setup.py install, looks like

[16:16:20] <dstufft> ngoldbaum: can it pass ``setup.py install --single-version-externally-managed`` ?

[16:17:02] <ngoldbaum> i think so? Is that option only recognized by setuptools? It shouldn't fail if setuptools isn't available

[16:18:24] <dstufft> it is setuptools only yes, but a fairly trivial patch to setup.py can fix that

[16:19:59] <dstufft> ngoldbaum: https://bpaste.net/show/c439c32acc75

[16:20:22] <dstufft> that should let you always pass --single-version-externally-managed to setup.py and it'll jsut remove it if setuptools isn't available

[16:26:04] <ngoldbaum> dstufft: on here, it says I should also specify --root and/or --record, but I don't see what those actually do

[16:26:12] <ngoldbaum> https://pythonhosted.org/setuptools/setuptools.html

[16:26:24] <dstufft> ngoldbaum: oh, one moment

[16:28:12] <dstufft> ngoldbaum: --record /dev/null should be fine

[16:28:40] <dstufft> or just any old file

[16:28:44] <dstufft> it don't matter

[16:29:36] <ngoldbaum> ok, going to try a v2 to at least get make wheel working out of the box

[16:29:39] <ngoldbaum> thanks again!

[16:30:10] <dstufft> ngoldbaum: an alterntive option is to look for bdist_wheel in sys.argv and only import setuptools if you're doing that

[16:30:33] <ngoldbaum> yeah, that's the root greg szorc is suggesting

[16:30:44] <ngoldbaum> route

[16:31:06] <dstufft> or switch setup.py install to be pip install

[23:27:44] <Earchcraft> is there way to ask freeze to use >= instead of == ? Is there any downside?

[23:34:43] <carljm> Earchcraft: No, there is no way built-in to pip; you could pipe the resulting file through sed or something. And yes, there is a downside: every env you create from that requirements file could be different in unpredictable ways, depending on when it was created and when new versions of your dependencies are released.

[23:36:08] <ngoldbaum> it wouldn't really be "frozen" requirements either

[23:36:16] <carljm> Freeze is meant to create a requirements file that will generate a reproducible env. A requirements file that uses >= instead of == doesn't generate a reproducible env.

[23:36:39] <carljm> That may be ok for some uses; for many it's not. I'd never do that in a requirements file that's used to install requirements for a production web service, for instance.

[23:37:15] <ngoldbaum> interestingly, the backward compatibility guarantees are much stronger in the scientific world. I've pretty much never broken anything updating numpy (for example)