Log file Viewer
#pypa-dev logs for Friday the 10th of April, 2015
[00:01:07] <ionelmc> lifeless: dstufft: quick question - won't wheel caching cause problems on 2.7 where wheel doesn't have the ABI tagging implemented yet? (like debug/wide different abis)
[00:01:44] <sevenhill> File "D:\python35\lib\site-packages\pip-1.5.6-py3.5.egg\pip\_vendor\distlib\scripts.py", line 290, in _get_launcher result = finder(distlib_package).find(name).bytes AttributeError: 'NoneType' object has no attribute 'bytes'
[00:02:12] <dstufft> ionelmc: possibly, we can fake the ABI on Python 2.7 (though we aren't right now). It's probably unlikely that someone has Python 2.7 with two different ABIs on the same machine though
[00:03:24] <dstufft> lifeless: it might be a good argument for an API that lets pip ask an sdist what the total set of wheels it can produce is
[00:03:33] <ionelmc> dstufft: i often have that problem, the debug python build helps with debugging
[00:04:11] <lifeless> dstufft: two different 2.7 ABI's - actually common on Ubuntu etc when folk need to debug things, they install the debug interpreter build
[00:04:16] <sevenhill> dstufft: i had 6.0.8 and it said you need to update after i tried it kissed my current version i pycharm installed 1.5.6 . And whenever i try to upgrade from it to 6.1.1 i'm getting that error
[00:04:36] <lifeless> ionelmc: my answer would be short term - disable the cache when doing debug work, longer term we fix that wheel bug
[00:05:11] <dstufft> ionelmc: open an issue please, I'll mark it so I don't forget to sort something out before 7.0 is released
[00:05:47] <lifeless> as any wheels you build won't be marked properly, so 'pip wheel' will build a bad wheelhouse
[00:07:03] <dstufft> sevenhill: https://github.com/pypa/pip/issues/2669 does this describe your issue?
[00:24:19] <dstufft> lifeless: I think the wheel building is a lot closer now (possible even ready to go sans the comments I've made so far), I want to think a little bit about if the sdist filename alone is enough of a cache key or not
[00:24:50] <sevenhill> lifeless: Removing temporary dir C:\Users\MERFAD~1\AppData\Local\Temp\pip_build_ÖmerFadıl <--- Ö and ı ( dotless ı ) might be a problem about it not sure
[00:26:23] <lifeless> dstufft: I don't think the filename is enough of a key, I think we need to validate that it looks like a versioned sdist rather (say) git+https://github.com/pypa/pip
[00:27:14] <lifeless> and there is no right key that wouldn't expose the 'and you used a different index' issue again
[00:28:52] <lifeless> oh, I hadn't changed the exception type - first time I've heard *raising* Exception referred to as bare :)
[00:30:47] <dstufft> So I'm trying to decide if "pip-6.1.0.tar.gz" is "unique enough" to be globally distinct or if we'd want to use the link.url as the cache key. The downsides of using link.url is you can't share caches amongst multiple indexes (like what Openstack does with it's per region indexes), so it's reallly trying to decide if the benefit of sharing a cache is worth the possible confusion if two things have two different "pip 6.1.0". With EP 440
[00:30:47] <dstufft> ideally nobody is re-using numbers like that but I doubt if we already convinced everyone to do that
[00:32:08] <dstufft> the old download cache (before we had the http cache) used the whole url as the cache key for the safety reason
[00:45:49] <lifeless> and uploading *different* contents with the same version to devpi and then to pypi
[00:48:55] <dstufft> lifeless: yea I agree with that in general, the primary concern being that users are often not going to be aware of this cache nor have much insight into what is inside it. I'm totally on board with having two different pip 6.1.0 tarballs being a bad thing (that's why PEP 440 added local versions). Just on the fence about whether It's OK for us to say that if you do that then this implicit cache thing is going to give weird results (and maybe
[00:48:55] <dstufft> that's fine, maybe we already have weird results if you do that and this is just another thing)
[00:50:20] <dstufft> lifeless: pip is a bit postel's tarpit, people do lots of strange things and trying to define the line between what might break and is OK to break, and what break and is not OK to break is always an interesting thing
[00:51:55] <dstufft> for now, I don't think you need to change it from filename to url, I'm just going to think about it some more
[00:59:04] <dstufft> lifeless: FWIW I think that the structure of this is correct. I'm going to play with it locally and put it through it's paces and stuff, but I think that any changes it would need are not going to be major structural changes
[01:25:57] <lifeless> dstufft: e.g. why does _egg_info_matches take the name as a parameter, rather than splitting on the last - before version strings?
[03:43:17] <lifeless> dstufft: when you wake up - https://github.com/pypa/pip/pull/2618 now has everything done I think
[19:19:51] <dstufft> couldn't leave the country with my daughter, or leave my daughter for that long
[19:34:13] <lifeless> dstufft: its my weekend now, but if you a) have time and b) have questions, I'll see what I can do about answering :)
[22:37:50] <ErikRose> dstufft: jezdez: Can one of you remind me why #sha256=abcde URL hashes don't suffice for peep's functionality? Is it just that we didn't want to turn every requirement line into a URL?
[22:46:43] <dstufft> ErikRose: you mean a requirements.txt file that has like foo==1.0#sha256=blah ?
[22:47:44] <dstufft> well for that, we don't want every requirements line to be an url because portability is great
[22:48:20] <ErikRose> I'm sitting here with some Twitter ops folks who thing it does. I'm picking through the source now.
[22:50:03] <ErikRose> wickman: The case I do think is true is that it checks the URL hash it gets from PyPI against the downloaded file to guard against transmission defects.
[22:54:13] <wickman> no, i'm saying that if we get a url with a #hash=ext, we at least verify it but that's it
[22:55:27] <wickman> pex will do it from requirements.txt as well (but the requirements.txt support is in a non-master branch atm)
[22:55:53] <dstufft> https://github.com/pypa/pip/issues/468 I know this because this is one of the first issues I ever opened on pip :D
[22:57:45] <ErikRose> I just hosted an open space on open-source burnout I wish we could have had you at.
[23:00:25] <ErikRose> Here's what I jotted down during it: https://gist.github.com/anonymous/44f10da267b0f17430c8
[23:06:46] <dstufft> ErikRose: I know some of these feels :( trying to manage incoming PRs can be hard
[23:07:22] <ErikRose> Admitting "I'm never going to look at this. I don't hate you. I just don't care enough or have time." is hard, too.
[23:08:07] <ErikRose> Everyone wants to submit patches, which is great. But few want to assume responsibility.
[23:08:29] <ErikRose> When I accept a PR, I am committing to support that code for the rest of my life. The submitted can just disappear into the internet mists.
[23:12:50] <ErikRose> tomprince: Interesting! I have toyed with trying this on one of my projects to see what happens.
[23:13:56] <ErikRose> I did deputize somebody on chardet. I said "Guess what: you're now a co-maintainer! Enjoy!"
[23:16:49] <tomprince> dstufft: Are you sure? It would certainly end up with a different result than the current one.
[23:22:13] <dstufft> yea, it's easy to just add quick fixes to a particular problem without thinking about the broader implications