Log file Viewer

[14:09:55] <daniel_holth> Anybody mind if I merge pip pr #3921 and #3922 ?

[14:10:38] <sigmavirus> dstufft: ^?

[14:11:55] <sigmavirus> daniel_holth: given you wrote both and there's been 0 code review, as a user of pip I wouldn't be very trustful that the code works

[14:12:07] <daniel_holth> Sweet

[14:12:28] <sigmavirus> daniel_holth: at least wait for xav or another person to review it before merging?

[14:12:42] <daniel_holth> There's quite a backlog of stuff

[14:12:46] <sigmavirus> maybe assign the PRs to one or more other people who can merge them?

[14:13:28] <dstufft> Did you check to see if #3922 actually works?

[14:13:30] <sigmavirus> yeah the backlog doesn't imply priority. I know xavfernandez has been doing a lot of review/merging

[14:13:32] <dstufft> I don't think it will....

[14:13:57] <dstufft> I mean, I don't think it's going to raise an error, but I don't think you're going to get the >= behavior

[14:14:24] <dstufft> oh nvm, you added all the platform tags

[14:14:26] <dstufft> for cpXY

[14:16:41] <daniel_holth> Hopefully you will be able to release only 2 cryptography wheels for all Python 3 Windows

[14:17:06] <dstufft> ugh

[14:17:09] <daniel_holth> With next wheel & cffi release

[14:17:10] <dstufft> CPython *shakes fist*

[14:17:19] <daniel_holth> Such c much Python

[14:17:22] <dstufft> `In some cases, the stable ABI needs to be extended with new functions. Extension modules wishing to use these new APIs need to set Py_LIMITED_API to the PY_VERSION_HEX value (see API and ABI Versioning) of the minimum Python version they want to support (e.g. 0x03030000 for Python 3.3). Such modules will work on all subsequent Python releases, but fail to load (because of missing symbols) on the older releases.`

[14:17:51] <dstufft> though I guess that would work by just using cp34 or so

[14:18:06] <daniel_holth> So the wheel tag gets to be cp33-abi3-(arch)

[14:18:37] <dstufft> Yea, the wheel tag logic makes my heard hurt a bit

[14:18:42] <dstufft> I always I have to think it through a few times

[14:18:42] <daniel_holth> Cffi was able to work with the original 32 abi with a tiny change

[14:19:00] <daniel_holth> Not cffi itself, just its extensions

[14:26:25] <dstufft> #3921 is bugs the pedant in me, I really don't think manylinux is less specific than a tag that will match on basically any linux system, but in practice the opposite is true :/

[14:27:27] <daniel_holth> The problem i have is how can i override a single manylinux wheel with something i can build locally

[14:28:28] <daniel_holth> Like the c++ exception abi that isnt in manylinux

[14:29:02] <dstufft> yea, I think the right way to do that is to enable custom platform tags which sort as the most specific tbh

[14:29:39] <daniel_holth> It depends on your point of view, and pip should have the point of view of the local system...

[14:33:16] <dstufft> I'm not sure what that statement even means, that pip should have "point of view of the local system"-- it has to decide which wheel is likely to be the best fit for a particular environment, and if there's a linux_64 wheel on a file server somewhere, there's no information to tell us how close of a fit that wheel is other than "linux, 64 bit"

[14:36:29] <daniel_holth> The theory is that you just have to know your server. Exactly the same as pointing rpm only at an rhel7 server. Compatibility is out of band.

[14:37:25] <dstufft> rpm and pip are different, are compatibility isn't usually out of band, it's usually in-band whereas for rpm the compatability is almost always out of band

[14:37:49] <daniel_holth> I would expect these to live mostly in local caches anyway

[14:39:58] <dstufft> where we expect them to live doesn't excuse us from having a coherent story for when they don't live there-- If pip has a custom platform tag ability, it takes one extra line to configure it, which they need to configure it anyways to point at the local cache

[14:45:18] <daniel_holth> So you suggest I configure my custom tag as linux_x86_64, my local toolchain builds them by default without changing bdist_wheel, Bob's your uncle?

[14:47:24] <dstufft> daniel_holth: No, I suggest you configure your custom tag as ``daniel_holth_linux_x86_64``.

[14:47:28] <dstufft> or something like that

[14:56:31] <dstufft> daniel_holth: don't have more time to discuss atm, commented on the issue, as well as another suggestion if you want it to still be automatic.

[14:57:45] <daniel_holth> Thanks

[14:58:16] <daniel_holth> Looking forward to seeing how the abi3 works

[17:51:21] <gnychis> dstufft, we were able to get the local packages being served by a separate nginx server for local hosting, thanks again for your help

[17:51:33] <dstufft> gnychis: No problem

[17:52:26] <gnychis> the only other issue we're seeing is that after we publish a new package, it's not showing up in the search. I see that warehouse is using elasticsearch... does something need to be called for it to rebuild its index?

[17:58:47] <dstufft> gnychis: um, currently yea there's a reindex command that rebuilds that

[17:58:54] <dstufft> eventually that'll be on demand, but not yet

[18:00:25] <gnychis> dstufft, this is the "reindex" command in the Makefile?

[18:00:49] <dstufft> gnychis: we don't run it via the Makefile, but yea basically

[18:02:41] <gnychis> dstufft, ahhh I see, I found warehouse/cli/search/reindex.py ... thanks again!

[18:04:00] <dstufft> gnychis: no problem! Fwiw, I'd be careful running migrations-- I often times do data migrations outside of the schema migrations with one off scripts that I don't bother to commit

[18:05:27] <gnychis> dstufft, sure thing, thanks for the heads up!