Log file Viewer

[01:31:41] <lifeless> dstufft: you mentioned a hack related to environment markers with wheels? I can't seem to find that ...

[03:29:58] <lifeless> dstufft: we currently call egg_info on editables before archiving

[03:30:13] <lifeless> dstufft: this doesn't make sense to me, since its still no a valid distribution.

[03:30:22] <lifeless> dstufft: I'm going to stop that, and you can tell me I'm nuts tomorrow :)

[13:22:32] <davidszotten> hi. what is “py version” for wheels on a package page on pypi populated by? e.g. https://pypi.python.org/pypi/requests/2.7.0 has py2.py3 in the filename but py versio 2.7

[13:46:13] <ronny> davidszotten: by either the configured tag or some flag,s when universal=1 is used for wheels, then it defaults to py2.py3

[13:46:44] <davidszotten> configured tag? in setup.py?

[13:50:31] <xafer> davidszotten, strange indeed, https://pypi.python.org/pypi/requests/2.6.0 has a "Py Version" equal to py2.py3

[13:51:34] <davidszotten> yes. actually trying to debug/understand this for my own package https://pypi.python.org/pypi/nameko but went looking for examples and now wondering how this actually works

[13:57:09] <xafer> it might depend of the tool used to upload

[13:59:51] <davidszotten> hm. just moved to having travis deploy

[14:35:18] <pf_moore> davidszotten: Not sure I understand the issue - python setup.py bdist_wheel has a --universal option to set py2.py3 (any Python version, basically) and a --python-tag that lets you specify what you want explicitly

[14:35:37] <pf_moore> --python-tag defaults to "pyN" (where N is your Python major version (2 or 3)

[14:35:54] <pf_moore> You can set the tag in setup.cfg, if you don't want to do it on the command line.

[14:36:41] <xafer> the issue is the "Py Version" metadata uploaded to PyPI, not the wheel file tag

[14:36:45] <pf_moore> Basically if you want to distribute a pure-python wheel that works for all versions, put "[bdist_wheel]\nuniversal=1" in setup.cfg

[14:36:54] <pf_moore> xafer: Ah, OK.

[14:37:09] <xafer> (at least, that was what I understood)

[14:38:14] <davidszotten> pf_moore: i have that in my setup.cfg (barring typos). didn’t know the relationship between that and (or indeed the existence of) tags, have just followed instructions to add universal to the apropriate section of setup.cfg

[14:38:49] <xafer> just search for "Py Version" on https://pypi.python.org/pypi/requests/2.7.0 then on https://pypi.python.org/pypi/requests/2.6.0

[14:39:39] <pf_moore> I don't think that's particularly meaningful, or used for anything. Like you say, possibly just what Python version did the upload.

[14:40:21] <pf_moore> Certainly pip doesn't use it for anything (i.e. because it says 2.7, doesn't mean you can't install on 3.4...)

[14:40:41] <davidszotten> pf:moore surely the upload couldn’t have been made with python version “py2.py3” (linked requests 2.6)

[14:41:19] <davidszotten> if pip ignores it and looks at the filename, everything should work fine though i guess

[14:41:36] <pf_moore> davidszotten: ah, it's even more meaningless than I realised :-) Maybe different tools fill in the value differently.

[14:42:16] <pf_moore> There's some legacy "not used for anything automatic, and not very useful as information" stuff in the PyPI metadata, unfortunately

[14:45:02] <pf_moore> Yep, looks like twine gets it from the wheel metadata (i.e., the filename tag): https://github.com/pypa/twine/blob/master/twine/commands/upload.py#L158

[14:47:06] <pf_moore> whereas distutils gets it from sys.version (https://hg.python.org/cpython/file/5c29bbcad278/Lib/distutils/command/install.py#l299)

[14:52:59] <dstufft> yes

[14:53:00] <dstufft> pf_moore: is correct

[14:53:05] <dstufft> also nothing uses that information to my knowledge

[14:53:11] <dstufft> I'm pretty sure it's informational only

[14:53:32] <dstufft> probably from a time when the expected use case was people manually downloading files with their browser

[14:54:02] <davidszotten> great, thanks

[15:26:48] <sigmavirus24> dstufft: my friend is trying to use pip and this happens to them: https://www.irccloud.com/pastebin/6khYeyK8

[15:28:39] <dstufft> um

[15:28:45] <dstufft> their Python appears to be messed up

[15:29:16] <dstufft> those hashes are guarenteed toe xist

[15:29:29] <dstufft> either it gets it from OpenSSL or it falls back to it's own built in implementation

[15:30:19] <sigmavirus24> Yeah

[15:30:20] <sigmavirus24> Just had them reinstall

[15:31:43] <dstufft> yea I dunno, never saw that error before

[15:32:02] <sigmavirus24> Also this is a rubby programmer

[15:32:04] <sigmavirus24> So

[15:32:10] <sigmavirus24> They were all freaked out