Log file Viewer

[08:58:23] <gutsytechster> pradyunsg: ping^^ regarding proposal review! :|

[09:34:57] <McSinyx[m]> hi gutsytechster, I'm applying for GSoC too

[09:35:04] <McSinyx[m]> what's your project?

[09:35:45] <gutsytechster> McSinyx[m]: Yeah, got to know from conversation from some days. It's great. :)

[09:35:59] <gutsytechster> McSinyx[m]: I am working on improving pip's test helper.

[09:37:40] <McSinyx[m]> nice! the current test set is a bit, ehm, inconsistent

[09:38:05] <McSinyx[m]> see you later

[09:38:12] <gutsytechster> It actually needs a good level of refactoring.

[13:06:48] <McSinyx[m]> gutsytechster: I'm not sure it's within your scope, but could you make the tests pass locally by default?

[13:07:47] <McSinyx[m]> currently I'm suffering from vcs ans env tests failure on master )-:

[13:42:00] <devesh> Hi Folks, I wanted some opinions on a PR, and what would be the right approach, as per the comment https://github.com/pypa/pip/pull/7927#issuecomment-605603170

[13:42:50] <devesh> It says that other maintainers can chime in, but do all maintainers get notified about every PR/issue comment, or is there an alias for PR makers to ask them?

[13:46:10] <McSinyx[m]> speaking as an user, either is OK to me, but were I an maintainer, I'd make such problem in the URL an error

[13:47:09] <devesh> Thanks McSinyx[m] for a suggestion, can we also do this? https://github.com/pypa/pip/pull/7927#issuecomment-605617463 (middle path) ?

[13:47:42] <devesh> BTW, how do we know who all are the maintainers for a project, is there a github webpage section for that?

[13:48:32] <McSinyx[m]> I don't think there's way (some can hide themselves from the org, also not every member of PyPA maintain pip)

[13:49:03] <McSinyx[m]> back on the other thing, I think you can just ping every once in a while for them to reconsider

[13:50:29] <McSinyx[m]> IMHO such problem only arise in the early stage of a downstream project, so they can quickly fix it either it's an error or a warning; thus it's purely pip's convention to handle, which I'm *not* familiar with

[13:51:47] <devesh> True McSinyx[m]

[14:19:21] <gutsytechster> McSinyx[m]: The tests passes for me locally. Which python version are you using?

[14:19:57] <McSinyx[m]> I'm on python 3.7 on debian gnu/linux

[14:20:30] <McSinyx[m]> problems are with hg and PipTestEnvironment

[14:20:59] <gutsytechster> Hmm, I am using python 3.6 and I am on Linux Mint Debian Edition.

[14:21:03] <McSinyx[m]> I'll rerun the tests and give you the full log

[14:21:05] <McSinyx[m]> wait a few minutes

[14:21:12] <gutsytechster> McSinyx[m]: Can you show the traceback?

[14:21:21] <gutsytechster> Ah! That's what I was asking for. Cool

[14:21:56] <McSinyx[m]> I can recall an issue but did not rmb it was you d-:

[14:36:31] <McSinyx[m]> gutsytechster: https://gist.github.com/McSinyx/4d08c96fdbc45f5fc8a54df8b17a5a29

[14:56:15] <gutsytechster> McSinyx[m]: Do you have hg installed in your system?

[14:59:28] <McSinyx[m]> I do, although I don't think I hg versioning of pip

[15:00:17] <gutsytechster> What do you mean by " I hg versioning of pip"? I didn't get it.

[15:03:22] <McSinyx[m]> I mean I don't think I cloned the hg history of pip

[15:05:59] <gutsytechster> McSinyx[m]: AFAICU, it seems you have an incomplete installation of mercury package.

[15:06:31] <gutsytechster> Maybe a dependency "hgdemandimport" is missing.

[15:07:50] <gutsytechster> I mean it definitely is missing. But since it runs the tests marked with `@need_mercurial` it means you got mercurial installation, but for some reason not something it uses.

[15:16:13] <McSinyx[m]> gutsytechster: you're right, my hg is outdated, I'm rerunning the tests now

[15:16:20] <McSinyx[m]> many thanks

[15:17:31] <gutsytechster> McSinyx[m]: my pleasure. I am also learning like this. :)

[15:21:45] <McSinyx[m]> gutsytechster: wait it doesn't work: https://gist.github.com/McSinyx/3cc735db297bd7e69577b5134ec7e60e

[15:22:27] <gutsytechster> Have you updated your mercurial installation?

[15:22:31] <McSinyx[m]> I can import tracing from hgdemandimport just fine in python3.7 interpreter

[15:23:10] <gutsytechster> That's weird!

[15:23:35] <gutsytechster> Are you running the tests in a virutal environment?

[15:23:52] <McSinyx[m]> things happenning in tox are weird, lemme find a vid I recorded a while ago

[15:24:04] <McSinyx[m]> yes, -e py3

[15:24:20] <McSinyx[m]> ^ this doesn't make sense sorry

[15:26:31] <gutsytechster> Ah ok. I was thinking something else. Leave it.

[15:27:05] <gutsytechster> So that takes us back to where we started. :/

[15:27:26] <McSinyx[m]> gutsytechster: off topic a bit but here's the vid

[15:27:44] <McSinyx[m]> https://www.youtube.com/watch?v=2fRnCxbuxJo

[15:28:02] <McSinyx[m]> gutsytechster: much worse than the starting point, where the issue seem trivial

[15:29:02] <gutsytechster> Yeah: maybe

[15:30:11] <McSinyx[m]> btw I'm heading to bed now, if you're from india (I think?) then you're 1.5h earlier than me

[15:30:18] <McSinyx[m]> goodnight everyone!

[15:30:40] <gutsytechster> Yeah, McSinyx[m]. I am from India

[15:31:01] <gutsytechster> No problem: Sleep tight.

[15:34:25] <gutsytechster> BTW, that thing happening in video, was really weird.

[17:17:44] <travis-ci> pypa/pip#15322 (master - 019637c : Jason R. Coombs): The build passed.

[17:17:44] <travis-ci> Change view : https://github.com/pypa/pip/compare/03f0ff440dee...019637cc6703

[17:17:44] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/668422195

[17:25:07] <pradyunsg> oh, gutsytechster quit.

[17:25:40] <pradyunsg> McSinyx[m]: o/

[17:25:45] <pradyunsg> Are you around?

[17:26:28] <pradyunsg> McSinyx[m]: it'd make sense to add the version constraint to our needs-mercurial check.

[17:26:42] <pradyunsg> What version of mercurial was it failing with?

[17:29:51] <pradyunsg> McSinyx[m]: your proposal seems fine to me. There's a decent amount of detail on what the changes needed are, and a fairly decent description of the details about the work. I do have a few suggestions...

[17:32:06] <pradyunsg> 1. Change the fallback "I'll do this if things don't work out" to something that doesn't need modifications to PyPI. A good candidate would be porting pip's option parsing logic over to something more modern than optparse. :)

[18:08:21] <pradyunsg> 2. It seems like we're trying to make parallel downloads work, is a mix of significantly advancing the state-of-the-art in the area, *and* trying to fit that into a codebase with a lot of technical debt. That makes me feel like this isn't appropriate for GSoC's structure (i.e. new contributor working on a well defined project, time boxed).

[18:08:49] <pradyunsg> s/we're trying/trying/

[18:16:39] <pradyunsg> 3. The download happens as part of the dependency resolution process and the "Implementation details" section would benefit from elaborating on how the dependency resolution process would interact with the downloading step; since the resolution process currently goes one-node-at-a-time but the downloading step wouldn't.

[18:18:27] <pradyunsg> </notes>

[18:21:06] <pradyunsg> gutsytechster, McSinyx[m], ssurbhi: thanks for being patient with me reviewing your proposal drafts! I was a bit swamped, with a lot of stuff other my OSS commitments taking up nearly all of my time.

[18:40:11] <devesh> Hi pradyunsg: I created a PR for my first stab at remove type: ignore from cli subpackage

[18:40:47] <pradyunsg> devesh: awesome! for future reference, it's useful to provide links when mentioning PRs/documents. :)

[18:41:12] <devesh> But I was wondering that since pip's internal api is not exposed to the consumer, only the command line, is the mypy effort specific to good coding practices by internal devs

[18:41:34] <devesh> Aah, I forgot the PR, sorry here it is: https://github.com/pypa/pip/pull/7932

[18:42:26] <devesh> That progress_bars.py is something else, quite a few inheritances going on, not easy to follow the code

[18:42:46] <pradyunsg> re progress_bars.py: yea lol

[18:43:13] <pradyunsg> I feel like switching us to a different library for progress bars would be a good idea. I just haven't found the time to do that.

[18:43:22] <devesh> So I changed whatever I think shouldn't affect the logic, since I didn't see unit tests for that and I didn't wanted to cause a regression

[18:43:50] <pradyunsg> re mypy: yes, the idea is to essentially bring in better practices for development.

[18:44:54] <devesh> btw don't mind me asking but are you working, or are you still in college?

[18:46:24] <pradyunsg> devesh: in college (4th year, 2nd sem); doing an internship that's allowing me to work on pip full time rn.

[18:48:10] <devesh_> pradyunsg: So almost out of college and into the real world :) Nice that you have so much OSS background with you.

[18:48:18] <devesh_> Will help you immensely in the industry

[18:48:35] <pradyunsg> :)

[18:48:41] <ssurbhi> pradyunsg: No issues. :) Would it be possible for you to do it now?

[18:49:10] <pradyunsg> ssurbhi: I *think* I responded already; but if I haven't, could you send me the link again?

[18:49:44] <pradyunsg> Aha! I did not -- it's sitting as a draft on my end!

[18:49:47] <devesh_> But yes, it's a good thing, I always wanted to start with OSS but never got the push, thanks to bangpypers that I got some taste of it.

[18:49:47] <pradyunsg> ssurbhi: ^

[19:02:00] <ssurbhi> pradyunsg: okay :)

[22:25:56] <devesh_> Hi pradyunsg: I wanted to add mypy annotations in the vcs subpackage: https://github.com/pypa/pip/tree/master/src/pip/_internal/vcs

[22:26:35] <devesh_> But I see that there are quite a few "return None", which would lead to a lot of Optional[Type], which will end cause problems with

[22:27:16] <devesh_> library functions like os.path.join, I think we can return say an empty string for str types etc, and check for that in calling functions

[22:27:30] <travis-ci> pypa/twine#1347 (master - f7402e0 : Brian Rutledge): The build passed.

[22:27:30] <travis-ci> Change view : https://github.com/pypa/twine/compare/5482d6877df0cd90545c4708e5abe13b359f8a08...f7402e0d2e1c1e6ecde61dc8bcba515b807a48a0

[22:27:30] <travis-ci> Build details : https://travis-ci.org/pypa/twine/builds/668509044

[22:27:31] <devesh_> That will simplify our types a lot

[23:38:22] <pradyunsg> devesh: the point of adding these types, is to ensure that we deal with those cases explicitly.

[23:38:28] <pradyunsg> Either through a conditional.

[23:39:15] <pradyunsg> Or through a blanket assert xyz, in cases where we know we won't see the None but mypy isn't able to infer that from context.