PMXBOT Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Tuesday the 5th of June, 2018

(Back to #pypa-dev overview) (Back to channel listing) (Animate logs)
[00:07:14] <Pharyngeal> teIt
[00:07:16] <Pharyngeal> oops
[00:19:50] <techalchemy> Pharyngeal: sorry for the extended 'brb' -- not sure if you had any success or not
[00:46:33] <Pharyngeal> techalchemy: still working on it - it's amazing how many things other than install depend upon pypi
[00:49:22] <techalchemy> Pharyngeal: the entire stack is quite complicated, which is why I usually push back against feature adds
[00:49:36] <Pharyngeal> Quite.
[00:49:45] <Pharyngeal> Trying my best not to break it ;)
[00:56:05] <techalchemy> changes to the resolver are particularly hard to debug :p
[00:56:34] <techalchemy> Pharyngeal: failing builds are currently being caused by attempts to determine the name of a package :p
[00:57:20] <Pharyngeal> techalchemy: heh, just made a whole bunch of changes and am now running tests. lots of fails :)
[00:57:40] <techalchemy> i just crtl+c out and start fixing in that case
[00:57:44] <techalchemy> you'll be waiting ages :p
[00:57:49] <techalchemy> i run tests on a ramdisk locally
[00:58:50] <Pharyngeal> I should give that a try
[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:29:45] <techalchemy> Pharyngeal: what's failing exactly?
[01:30:00] <techalchemy> use test.pypi.org
[01:30:14] <Pharyngeal> Oh. Did not know. Will give that a try, then.
[01:30:20] <Pharyngeal> Thanks
[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:03:15] <techalchemy> Oh I see
[02:03:33] <techalchemy> you can't, probably
[02:03:33] <techalchemy> :p
[02:03:43] <techalchemy> I think I switched on the JSON api
[02:03:46] <techalchemy> let me check
[02:04:44] <Pharyngeal> Why does the appveyor build cancel itself sometimes
[02:05:41] <techalchemy> because uh
[02:05:57] <techalchemy> if you had a build in the queue and then you re-push or something like that
[02:06:08] <techalchemy> it queues the new commit and cancels the old one
[02:06:14] <techalchemy> Pharyngeal: pip_options=pip_options, use_json=True, session=session
[02:06:16] <techalchemy> in utils.py
[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:08:54] <techalchemy> I'm not worried about it
[02:08:57] <Pharyngeal> :)
[02:09:14] <techalchemy> I like the iteration, it gives me a lot of confidence
[02:09:55] <techalchemy> it also captures the essence of what it's like to work on this project most of the time :p
[02:10:07] <Pharyngeal> The architecture is ... interesting
[02:10:35] <techalchemy> there is a reason we have broken out a separate organization and started building libraries and using them
[02:10:40] <techalchemy> instead of writing code in pipenv directly
[02:12:25] <Pharyngeal> techalchemy: What should fail if use_json=True?
[02:12:31] <Pharyngeal> I haven't seen any failures yet
[02:12:45] <techalchemy> technically it will still hit the jsonapi for resolution
[02:12:50] <techalchemy> it just won't tell you about it
[02:13:03] <techalchemy> it supplements resolution data
[02:13:06] <Pharyngeal> I've blacklisted pypi.org on my test machine
[02:13:14] <Pharyngeal> Does it fail graciously?
[02:13:27] <techalchemy> i suspect it will slow your test run down
[02:13:32] <techalchemy> but it should be fine otherwise
[02:13:38] <Pharyngeal> Oh, okay
[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:15:32] <techalchemy> kind of
[02:15:52] <techalchemy> I just dont know anything about that pytest extension tbh other than that it serves up the simple interface
[02:15:56] <Pharyngeal> right, I'd have to write test cases overriding that behavior
[02:16:28] <techalchemy> you should just be able to not pass in that pypi arg
[02:17:09] <Pharyngeal> techalchemy: Which arg?
[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:33:35] <techalchemy> or a suggestion :p
[02:33:42] <techalchemy> if I have one
[02:34:27] <Pharyngeal> Yeah, I might do a little bit more tonight depending on whether I can finish some other stuff
[02:34:29] <Pharyngeal> Thanks
[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?
[10:25:25] <lumir_> hello
[20:33:23] <sumanah> hi sigmavirus24
[20:33:46] <sumanah> sorry I missed you when I was in Madison in May!