On Wed, Apr 06, 2011 at 12:37 -0400, Vyacheslav Rafalskiy wrote: > > Not exactly. You can use a .ini file to add command line options: > > > > http://pytest.org/customize.html#adding-default-options > > I wouldn't want to maintain an extra config file. I already have > conftest.py with > a lot of hardcoded stuff, a bit more does not hurt. Moreover, if you put it > like > > def pytest_cmdline_preparse(args): > args[0:0] = [ > '--verbose', > '--capture=no', > ] > > it looks even cleaner than using option_xxxx variables in spite of a > bit of boilerplate.
Sure, if you have a root conftest.py anyway that works. Note that you can put the .ini config into a setup.cfg as well which is used by the upcoming python package distribution as well (and setuptools). > >> 3. In my pytest_configure() there are numerous conditions when it can > >> fail. For this > >> conditions I have exceptions with specially crafted messages, intended > >> for different > >> people. Now they are gone, replaced by a long and scary listing with every > >> line > >> prepended with INTERNALERROR. What is internal about it? Can I continue > >> managing > >> my configuration errors? > > > > Sure, you should be able to. I guess it was a bit of an incident that > > failures in pytest_configure were shown nicely. I am not quite sure > > immediately what the best way to relay "global" configuration messages > > to the user is. If you'd use "funcargs" and the "session" scope for > > setting up resources then it would show nicely. Feel free to open > > a feature/enhancement request to have py.test show failures > > in sessionstart or configure hooks in a way that helps you. > > This way we can write a specific test and make sure it works > > also in the future. > > If I understand correctly, using funcargs means that every test function > of hundreds I have in several suites should include a reference to the > global setup funcarg. It seems a non-starter. > > I guess I will stick to the old version and try to think of something > to enter in a feature request. sure, makes sense. isn't your main issue that upon actual test start (after collection) you want to do some configuration steps which might result in error conditions which you'd like to see nicely reported to the user? (sidenote: configure and even sessionstart hooks are both a bit not 100% right because they happen even on the master side of a distributed test run and the master side does not collect or run tests at all) best, holger > Vyacheslav > _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
