[py-dev] migration from 1.3 to 2.0

[holger krekel]

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
>