[01:03:00] <Pharyngeal> Looks like it was a bug I introduced into the resolver ^_^
[01:17:41] <Pharyngeal> techalchemy: I'm going to need an alternative test method, it seems. pypi.python.org testing fails because it'll redirect all requests
[01:17:55] <Pharyngeal> Which, will pass, but not if pypi.org is inaccessible
[01:18:14] <Pharyngeal> So, the tests might not truly show that the dependency on pypi is removed
[01:19:08] <Pharyngeal> I think the hardest part about this PR will be the test cases
[01:31:27] <techalchemy> https://dpaste.de/MWRC if you want to have some ramdisk tests
[01:39:57] <Pharyngeal> techalchemy: Using test.pypi.org as the mirror still sends some traffic to pypi.org it seems
[01:58:47] <techalchemy> Pharyngeal: what are you testing for exactly/
[02:00:20] <Pharyngeal> techalchemy: Basically want to run all operations assuming pypi.org is inaccessible to make sure there are no hidden usages of it
[02:00:38] <Pharyngeal> which I've done successfully locally, but trying to figure out the best way to write test cases.
[02:00:58] <techalchemy> is testing against the local index we run in the tests not working?
[02:02:22] <Pharyngeal> techalchemy: All the existing tests pass. I want to write additional tests that prove that pypi.org is not used if --pypi-mirror is specified
[02:06:22] <Pharyngeal> I don't think that's been the case, but whatever
[02:06:32] <Pharyngeal> techalchemy: What's that for?
[02:06:50] <techalchemy> I'm not 100% convinced we should use the json api yet but you should make sure that is set to 'False' if a pypi mirror is in use
[02:07:09] <techalchemy> it hits the pypi json api for dependency resolution as a backup resolver
[02:07:17] <Pharyngeal> techalchemy: Mirrors do not mirror the API, I take it?
[02:07:28] <techalchemy> I don't know enough about the implementation specifics to answer that
[02:07:44] <techalchemy> I don't think they do yet at least
[02:08:13] <Pharyngeal> Makes sense, ;et me address that
[02:08:47] <Pharyngeal> Also, don't worry about the commit messages, I'll rebase before submitting the PR for inclusion
[02:14:28] <Pharyngeal> so, do you think it's possible to test blocking pypi and using mirrors for each command? It doesn't seem feasible to me unless we use an actual mirror, but there are no public ones I'd feel comfortable using
[02:15:11] <techalchemy> we technically mirror pypi locally
[02:17:25] <techalchemy> 'pypi' gets passed into our test cases all over the place as a fixture
[02:18:18] <techalchemy> just dont pass it in and grab the url from PIPENV_TEST_INDEX and then unset that env var in a 'temp_environ' context manager
[02:19:09] <Pharyngeal> I don't think this will help prove what I need it to prove, but I could be confused
[02:21:26] <techalchemy> Pharyngeal: possibly not, it gives you access to a locally running pypi 'mirror' with some packages you can try to install while hiding the fact that it is in fact the test instance from the test runners
[02:32:52] <Pharyngeal> techalchemy: Looks like I might be winding down my efforts for the night, gotta get to some other matters. It looks like it's working as expected, except for one failing test on Python 2 on Windows. I'll take a look at that and consider my additional integration tests soon, maybe tomorrow, maybe Wednesday
[02:33:09] <techalchemy> no worries, thanks again for all your work on it
[02:33:27] <techalchemy> I'll look it over if I am hurrying to release and make a call about those
[02:51:40] <mbacchi> I have a WIP PR in warehouse (#890) that seems to be affected by PR #3367 which changed many migrations and now alembic in my branch is complaining: https://travis-ci.org/pypa/warehouse/jobs/388056080#L1364
[02:52:10] <mbacchi> Any ideas on what I can do to work around that? or should I just wipe out my WIP PR and start again?