[py-dev] migration from 1.3 to 2.0

[Vyacheslav Rafalskiy]

Thanks Holger,

On Tue, Apr 5, 2011 at 4:16 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Vyachselav,
>
> On Tue, Apr 05, 2011 at 11:42 -0400, Vyacheslav Rafalskiy wrote:
>> Hi Holger and list members,
>>
>> I have been using py.test for some time after switching from nose and
>> quite happy with it.
>> However, when migrating from 1.3.1 to 2.0.2 I hit a couple of snags,
>> which makes me hesitate.
>> Perhaps you can help me.
>
> can try but am only online intermittently currently.
>
>> 1. Just to clear the point. I understand from another post that
>> option_xxxx variables
>> in conftest.py are gone and recommended replacement is to use
>> pytest_cmdline_preparse().
>> Is that so?
>
> 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.


>> 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.

Vyacheslav