Log file Viewer

[01:57:10] <Pharyngeal> techalchemy: Welcome back

[02:12:08] <techalchemy> Pharyngeal: Thanks -- I saw some discussion on your pr

[02:12:27] <techalchemy> haven't had a chance to look yet but at a high level do you think it's good to go?

[02:12:51] <Pharyngeal> Yeah, it's almost done I think. TP found some debug stuff I accidentally left in, which led me to find one function in misc that didn't have the pypi_mirror param added yet. All fixed now.

[02:13:01] <Pharyngeal> I think so. Unless you think it needs additional test cases.

[02:13:28] <Pharyngeal> I did some basic acceptance testing on a machine on a network which blocks PyPI, and all of the basic operations worked as expected.

[02:23:00] <techalchemy> Pharyngeal: I doubt I'll ask you to add any coverage to it, it's pretty difficult to adequately cover our codebase atm

[02:23:27] <techalchemy> my focus is on breaking things apart

[02:23:32] <Pharyngeal> techalchemy: I've added integration tests that should reflect the proper operation of install, sync, and lock

[02:23:44] <Pharyngeal> And some variations

[02:23:52] <techalchemy> Pharyngeal: I will have a look, that is quite helpful if so

[02:24:34] <techalchemy> I sat down to start working on `--selective-upgrade` yesterday and started untangling all of the duplicated code we have in our locking functionality

[02:24:38] <Pharyngeal> Hopefully they're adequate, but I know some stuff is lacking (like mirror tests for get_vcs_deps)

[02:24:54] <techalchemy> it's just super painful to work with that code

[02:24:59] <Pharyngeal> Which?

[02:25:03] <techalchemy> the VCS code

[02:25:08] <techalchemy> anything that touches locking

[02:25:19] <techalchemy> anything in the core library :p

[02:25:35] <Pharyngeal> oh, yes.

[02:25:41] <Pharyngeal> It's... an exercise.

[02:25:43] <techalchemy> where we have click interspersed in the entire codebase

[02:26:12] <techalchemy> I need to lay out a plan somewhere for what needs to happen to the code

[02:26:21] <Pharyngeal> I don't know whether to blame the length of time I worked on this on the codebase, or my own inexperience

[02:26:33] <techalchemy> no it's not you

[02:26:42] <techalchemy> the simplest tasks take an eternity

[02:27:43] <techalchemy> I've probably spent thousands of hours on this project and I still have to re-read everything and do the equivalent of tracing the lines with my finger

[02:28:22] <Pharyngeal> techalchemy: Yeah, I had a separate text editor open where I was mapping what called what and whether it needed pypi_mirror or not.

[02:28:27] <Pharyngeal> Evidently I missed one.

[02:28:37] <Pharyngeal> But that's since been resolved.

[02:29:37] <techalchemy> We need a clear path forward

[02:29:45] <techalchemy> the current codebase isn't really sustainable

[02:30:24] <Pharyngeal> Also, https://ci.appveyor.com/project/pypa/pipenv/build/job/t48wk7gtn1hv64gs

[02:30:47] <techalchemy> yeah that failure is non-deterministic

[02:31:03] <Pharyngeal> Could you help me figure out what's going on here? This test is failing inconsistently, and I haven't changed anything that should affect it since the last successful appveyor build

[02:32:23] <techalchemy> Yeah so this test is designed to capture a marker grouping regression related to our ignoring compatibility flags

[02:32:49] <Pharyngeal> So how should its results be interpreted?

[02:33:17] <techalchemy> basically because we ignore compatibility flags, we get all of the dependencies associated with the package in question if we ignored a compatibility flag we turn it into a marker, that test makes sure that that actually happened

[02:33:35] <techalchemy> when this test fails, it usually is because of a race condition that actually just prevents those depenedencies from resolving properly

[02:34:15] <Pharyngeal> Inconsistently?

[02:34:30] <techalchemy> yep

[02:34:30] <techalchemy> https://ci.appveyor.com/project/pypa/pipenv/build/job/t48wk7gtn1hv64gs#L423

[02:35:03] <techalchemy> I am not honestly sure why it fails, if I had to guess I'd say it relates to some of the parallel installs that are going on

[02:35:20] <techalchemy> it makes a fresh virtualenv on that line after installing things

[02:35:28] <techalchemy> but only sometimes

[02:35:45] <techalchemy> I only ever see this failure on CI

[02:36:32] <techalchemy> I can honestly say I have no idea why, I'm not an expert at pytest to begin with

[02:36:35] <Pharyngeal> I got it locally, but only once.

[02:37:11] <Pharyngeal> How should I note that that's a false-failure?

[02:40:51] <techalchemy> Pharyngeal: ignore it, it won't hold up your PR

[02:40:57] <Pharyngeal> Alright

[02:41:26] <techalchemy> it's well known, but I don't have a solution yet

[02:43:53] <Pharyngeal> Understandable

[03:03:50] <pradyunsg> !logs

[03:03:50] <pmxbot> http://kafka.dcpython.org/channel/pypa-dev

[10:37:27] <jameshowe> is there an ETA for the next pipenv release?

[15:00:55] <techalchemy> jameshowe: probably in the next day or two

[15:01:38] <jameshowe> techalchemy: thanks, as you can see from my issue activity I'm having a lot of fun :)

[21:03:14] <cooperlees> Or we go into a PR battle royal again ...