Log file Viewer

[05:30:48] <techalchemy> o/ @ ncoghlan

[05:39:18] <pradyunsg> !logs

[05:39:18] <pmxbot> http://kafka.dcpython.org/channel/pypa-dev

[05:40:15] <ncoghlan> @techalchemy o/

[05:41:01] <ncoghlan> despite using \o/ regularly, it took me a moment to realise that o/ was waving :)

[05:49:16] <pradyunsg> techalchemy: I will try to find some time next week to write that pip internals docs.

[05:49:26] <pradyunsg> :)

[05:49:41] <pradyunsg> ncoghlan: o/

[05:50:54] <pradyunsg> techalchem: (no promises though)

[05:52:16] <ncoghlan> techalchemy: thanks for pinging me on those thorny design questions :)

[05:52:56] <techalchemy> ncoghlan: my pleasure :) some of them feel a bit above my paygrade

[05:53:07] <techalchemy> pradyunsg: no rush, I can work through most of it on my own

[05:53:07] <ncoghlan> I'm not sure I'll get to a point of directly contributing code fixes any time soon, but design I can definitely help with :)

[05:53:19] <techalchemy> ncoghlan: I wouldn't recommend it, it's not necessarily easy to follow :p

[05:54:36] <ncoghlan> techalchemy: I'd set aside some time to do it because I really wanted the `--keep-outdated` feature

[05:55:32] <ncoghlan> but with that implemented, I'm now at the point of "it does everything *I* need" :)

[05:59:27] <techalchemy> ncoghlan: I'm fairly sure it's not working completely right at the moment, but I've been 100% focused on test infrastructure the last 2ish weeks

[06:00:02] <techalchemy> ever since we moved over to jenkis/killed appveyor, etc. Then discovered that actual failures werent bubbling up

[06:00:24] <ncoghlan> yeah, Kenneth reopened the issue due to problems with the lock file changing when it should have been left alone

[06:01:04] <techalchemy> I have about 90% of a refactor of requirements parsing finished to just expose an API that allows us to call .to_pipfile() and .to_requirement()

[06:01:20] <techalchemy> which will be step 1 of 9999999 in cleaning up some of our internals

[06:01:42] <ncoghlan> \o/

[06:02:00] <techalchemy> + a reimplementation of python finder logic which spans like 16 function calls right now

[06:03:46] <techalchemy> PythonFinder.from_version('3.6') => uses the pep514 finder on windows, falls back to searching the path, looks for pyenv if it exists

[06:03:50] <techalchemy> on *nix

[06:05:35] <techalchemy> but yeah thanks for your ongoing help on the difficult issues, that's the stuff where I really need the most support atm since the rest of the folks are in a bit of a lull period (nate is primary on requests atm I think)

[06:19:16] <techalchemy> ncoghlan: one of the big things i'm thinking about is ways we can locally cache the dependency graph (or improve on it) so that we don't have to keep re-resolving stuff we already know about

[06:20:06] <ncoghlan> yeah

[06:20:08] <techalchemy> I know things aren't truly deterministic but for practical purposes if you resolve a specific version on a specific abi tag on a specific platform from a package index it's probably not changing next time

[06:20:29] <ncoghlan> I'm wondering if you may actually want two levels of caching

[06:20:44] <ncoghlan> one level in the lock file itself, so it transfers across machines

[06:21:14] <ncoghlan> and another akin to the pip wheel cache, where you can share resolutions across projects built on the same machine

[06:21:18] <techalchemy> that would be really, really nice, given the kinds of issues people are reporting atm

[06:21:52] <techalchemy> at the moment it's more of an ethereal idea but I don't think the implementation is that hard, I just think defining the behavior is

[06:23:25] <ncoghlan> and avoiding scope creep - speeding up relocking the same version will be much easier than speeding up recalculation of modified trees

[06:28:03] <ncoghlan> Anyway, I'm off - thanks for all the great work on pip, pipenv, et al! :)

[06:38:36] <techalchemy> pradyunsg: zazo flattens dependency graph?

[06:41:30] <pradyunsg> techalchemy: yes, it should but I'm not sure if it does it properly in all cases _yet_.

[06:52:23] <techalchemy> pradyunsg: the resolution strategy would prefer the most recent version that satisfies all markers if possible then?

[06:54:57] <pradyunsg> techalchemy: nothing in zazo deals with markers or "preference" of versions; that'll be implemented as pip's support code for zazo. That said, yes, that'll be the default strategy.

[07:01:08] <techalchemy> kk

[07:01:34] <techalchemy> pradyunsg: so zazo is just an abstraction then, do you have / have you worked on an implementation?

[07:01:49] <techalchemy> that is on the agenda for us at some point I guess

[07:02:24] <techalchemy> we jsut print generic errors now and tell people to install with --skip-lock and print the dependency graph to figure out the problem manually

[07:04:11] <pradyunsg> techalchemy: I had started working on an implementation for pip but dropped that till zazo gets to a better place.

[07:06:37] <pradyunsg> techalchemy: yes, zazo is just an abstraction with just an algorithm + 2 abstract classes coded up right now. My intention is to implement a couple of semi-concrete classes that packaging would build upon (they'll handle details of extras/markers and the consumer would deal with the order).

[07:08:05] <techalchemy> okay, thanks for the info pradyunsg. Depending on how far away we are from somethihg like that with our current codebase (I suspect reasonably far) we may want to figure out how we can help

[07:10:37] <pradyunsg> techalchemy: Sure! Lemme know. :)

[07:11:17] <pradyunsg> I feel there's a lot I want to add to zazo until I reach a "usable by a Python packaging tool" state -- backjumping (it's just dumb backtracking) + topo sorting + nice conflict reporting and more but the idea is that the abstraction should allow me to do these transparently.

[07:11:51] <pradyunsg> (I might probably drop some of these features if they're not critical or time does not permit.)

[07:12:22] <techalchemy> pradyunsg: we currently hack stuff together until it sort of works and make things work 'properly' in bugfixes

[07:22:48] <pradyunsg> techalchemy: There's a YAMLProvider that powers the tests -- that's sort of the initial prototyping variant of a Provider I had created for, well, testing. :P

[07:29:48] <techalchemy> pradyunsg: cool, I'll have a look

[07:29:55] <techalchemy> maybe we can whip something up :p

[16:12:06] <ilovezfs_> https://github.com/Homebrew/homebrew-core/pull/26034

[19:52:10] <yeray> happy easter everyone

[22:26:54] <thea> \o/

[22:33:28] <di_codes1> thea: except I just noticed we’re not consistent with the identifier listed at <https://tools.ietf.org/html/rfc7764#section-3.2>

[22:33:42] <di_codes1> gonna do a minor version release to fi

[22:33:46] <di_codes1> *to fix

[22:33:59] <thea> its uppercase instead of lowercase?

[22:34:11] <thea> should we just be case-insensitive about the variant?

[22:37:31] <di_codes1> thea: yeah, seems so. i think it’d be better for there to just be one way to do it that’s consistent with that RFC

[22:37:46] <thea> yeah but I was thinking on the robustness principle here.

[22:38:22] <thea> I'll also need to send another warehouse PR to fix the casing. I'll do that so you don't have to.

[22:41:52] <thea> di_codes1: ^

[22:43:01] <thea> pyup should send the PR to update the readme_renderer version once you upload. Let me know if you need me to upload instead. :)

[22:53:09] <di_codes> thea: pyup lags a bit, if you can check the “allow edits from maintainers” box i can push a commit that bumps the readme_renderer version to your PR

[22:54:52] <thea> Sure one sec

[22:55:23] <thea> it's checked. :)

[22:59:11] <di_codes> thea: weird! i’m getting a “permission denied”. guess i’ll just make it a separate PR

[23:03:22] <thea> Weird

[23:03:44] <thea> Will review the user guide pr in just a second.

[23:06:03] <thea> di_codes: I'll let you pull the "merge" button on that when you're ready. It's approved. :)

[23:08:55] <di_codes> thea: ha, just commented on it. don’t have the commit bit on that repo yet

[23:09:08] <thea> lol fun

[23:09:44] <thea> I'm hesitant to merge this until I can test and verify that warehouse is indeed defaulting to GFM.

[23:11:42] <di_codes> thea: <https://test.pypi.org/project/bokeh/> &lt;- has GFM tables

[23:12:23] <thea> Oh wow, when did you test that?

[23:13:22] <di_codes> thea: wasn’t me!

[23:13:58] <thea> I am confused. how does this work, then?

[23:14:38] <di_codes> thea: we switched the default, so anyone who previously specified `text/markdown` now gets GFM

[23:15:01] <thea> ah I see. So this started working when we merged the "update readme_renderer to 18.0" PR on warehouse?

[23:15:07] <di_codes> thea: yep :slightly_smiling_face:

[23:15:20] <thea> Is it retroactive or did they upload a new version between then and now?

[23:17:02] <di_codes> thea: i think that release technically came after we merged that, but it is retroactive because the descriptions are rendered per-request

[23:17:36] <thea> Interesting, I was not aware of that.

[23:18:22] <di_codes> hence the “folks that currently have semi-broken Markdown descriptions will magically get them fixed” bit here: <https://github.com/pypa/readme_renderer/pull/72#issuecomment-377646879>

[23:18:26] <di_codes> (sorry that wasn’t clear!)

[23:18:41] <thea> very cool!

[23:19:02] <thea> so is this also the case on pypi.org (or is it just rolled out to test.pypi.org at this point?)

[23:19:22] <di_codes> thea: nope, they deploy simultaneously, so both

[23:21:15] <thea> \o/