Log file Viewer

[12:17:09] <gtristan> So I am using the convenient test_suite=<directory name>, parameter to setuptools, and would just like to disable the obnoxious ordering on the default unittest TestLoader which setuptools implements

[12:17:49] <gtristan> Is there a simple way I can access the effective loader instance so I can just call sortTestMethodsUsing (None) on it ?

[12:18:00] <gtristan> without reimplementing my own loader from scratch ?

[12:46:16] <agronholm> why not use a better testing tool like pytest?

[12:46:29] <agronholm> and why does test order matter?

[12:47:34] <gtristan> agronholm, A.) Because I prefer to have minimal dependencies, and unittest is builtin afaik B.) Because it's important to me, as my test suite(s) grow, to see low level tests fail first

[12:48:12] <gtristan> Ideally, I would prefer that by default, the first failing test aborts the test run, with an optional --keep-going method

[12:48:28] <agronholm> well, I hope you never need to develop a node.js app

[12:48:40] <agronholm> if you think one extra dependency is bad...

[12:49:00] <agronholm> in a typical node app the deps run in the hundreds

[12:49:07] <gtristan> When a test fails, which tests something lower level in my codebase, I don't expect higher level tests depending on the failing code to pass, I dont want to parse through failing tests which I would not expect to pass

[12:49:34] <agronholm> well, you can use the loader to only run low level tests

[12:50:56] <gtristan> I'm not sure how to do that, right now I'm trying to work around setuptools and that works, but the output is a little dumb compared to the setuptools builtin loader

[12:51:14] <gtristan> It just says: "N tests passed, OK"

[12:51:15] <agronholm> with pytest you can

[12:51:24] <agronholm> pytest is immensely more powerful than unittest

[12:54:09] <gtristan> Seems weird, test frameworks should not be complicated in themselves, how is pytest more powerful ?

[12:54:49] <agronholm> with a simple decorator, you can generate more tests from a single test function using a number of parameters

[12:55:04] <agronholm> let me paste you a link

[12:56:01] <agronholm> github.com/asphalt-framework/asphalt/blob/master/tests/test_context.py#L248

[12:56:35] <agronholm> you can easily share fixtures across class, module or package boundaries

[12:56:46] <agronholm> and override them on lower levels if you need to

[12:56:51] <gtristan> I see, that looks like a good thing

[12:56:52] <agronholm> even parametrize them

[12:57:17] <gtristan> So that is basically 2 tests in one, instead of just doing a loop

[12:57:31] <agronholm> they also show up as 2 tests in the collector

[12:57:57] <agronholm> if you add another @pytest.mark.parametrize, you can create a 2xN matrix of test parameters

[12:58:31] <gtristan> And (excuse not a pythonic person here), I suppose any of these frameworks will have some easy support for expecting exceptions ?

[12:58:39] <agronholm> indeed

[12:59:00] <agronholm> github.com/asphalt-framework/asphalt/blob/fe83ffa7c04e8d280f88a48ad11749fcb70fb38a/tests/test_context.py#L74

[12:59:14] <agronholm> or: github.com/asphalt-framework/asphalt/blob/fe83ffa7c04e8d280f88a48ad11749fcb70fb38a/tests/test_context.py#L256

[12:59:35] <agronholm> you can catch warnings in a similar fashion

[12:59:59] <agronholm> you can see that most of those test functions have parameter declarations

[13:00:19] <gtristan> warnings are always annoying to catch

[13:00:23] <agronholm> pytest then injects the named fixture in the call

[13:00:31] <agronholm> no, with pytest they're easy to catch

[13:00:52] <agronholm> doc.pytest.org/en/latest/recwarn.html

[13:00:58] <gtristan> I mean, in an evolving codebase, a warning message is generally not functionality, but UX

[13:01:17] <gtristan> it's always easy to string compare (but sometimes obnoxious to catch stderr)

[13:01:35] <gtristan> but buddy comes along and perfects the wording of a message

[13:01:45] <agronholm> ?

[13:02:03] <gtristan> then many tests need to be updated just because the wording of the error message was improved

[13:02:18] <agronholm> search and replace?

[13:02:40] <gtristan> yes yes

[13:02:50] <gtristan> so pytest

[13:03:26] <agronholm> yeah, don't bother with that

[13:04:36] <gtristan> I see you are using those async things... I will be scheduling some sub processes to perform tasks in parallel, and was looking at that async & wait stuff last week

[13:04:53] <gtristan> This is basically event loops integrated into python yes ?

[13:05:21] <agronholm> async/await does not bind your code into a particular event loop implementation

[13:05:23] <gtristan> it's pretty recent python 3.5 minimum ?

[13:05:32] <agronholm> for async/await syntax it is

[13:05:49] <agronholm> but async frameworks have existed in python for a long time

[13:06:00] <agronholm> and the asyncio implementation requires python 3.3+

[13:06:08] <agronholm> (the yield from syntax)

[13:06:09] <gtristan> I see, so if I want to use that, I need an implementation of it

[13:06:23] <agronholm> the standard library contains asyncio from 3.4 onwards

[13:06:27] <agronholm> but I recommend 3.5+

[13:06:30] <gtristan> Ah, I see

[13:06:47] <gtristan> thanks for that tip :)

[13:07:06] <agronholm> curio is a third party experimental lib that uses the async/await syntax but without an explicit event loop

[13:11:09] <agronholm> twisted also recently gained support for the async/await syntax

[13:15:59] <gtristan> Ok you've sold me on pytest :)

[13:16:02] <gtristan> heh

[13:17:08] <gtristan> basically I want to run an event loop, schedule tasks in the event loop, and I want callbacks to be invoked when those tasks complete so I can schedule more tasks

[13:17:21] <gtristan> I think async/await (iiuc) is the pythonic way to do that

[13:17:23] <agronholm> yes

[19:32:29] <asfaltboy> Hi guys, question for you reg. auto-creation of wheels. I'm pretty sure this has been discussed before, but why won't "warehouse" (or some related worker) support auto building wheels for common platforms/architecture and python versions?

[19:33:11] <tdsmith> the distutils-sig archives have a lot of talk about this recently

[19:33:23] <asfaltboy> tl;dr ?

[19:33:25] <tdsmith> my impression is that technical challenges aside the PSF doesn't have stable resources to commit

[19:33:38] <asfaltboy> thought it's resources

[19:39:15] <tdsmith> yeah, i think everyone wants it

[19:39:34] <tdsmith> i'm not an important player in this conversation though ;)

[19:40:52] <asfaltboy> I think we are all important, in raising our voice that is

[19:41:10] <asfaltboy> the question is, who's gonna pour dollars into this

[19:41:30] <tdsmith> something something tragedy of the commons

[19:42:17] <asfaltboy> o well, "here's to a better future!"

[19:47:24] <asfaltboy> People can probably use travis and appveyor to build their wheel meanwhile

[19:47:30] <asfaltboy> s/build/publish

[19:47:44] <asfaltboy> both actually

[20:09:35] <pmxbot> Zoiks! An error occurred: mongodb.jaraco.com:27017: [Errno 110] Connection timed out

[20:09:35] <pmxbot> ! None