[py-dev] py.test and editors (Re: [issue57] Emacs and py.test tracebacks)

[holger krekel]

Hi Ralf, 

On Wed, Jul 23, 2008 at 14:43 +0200, Ralf Schmitt wrote:
> On Wed, Jul 23, 2008 at 1:34 PM, holger krekel <holger at merlinux.eu> wrote:
> 
> > I think it's fine to have the decorator mostly stay forever.
> >
> 
> It looks like you want that decorator to attach more information to
> test functions.
> In the case where you only want to mark a test as expected failure, I
> think it should be removed.
> 
> > I think that py.test should usually always run the
> > "bug" test but report them specially (no tracebacks)
> > if they fail and maybe
> >
> >    .........bb...................
> >
> > for the progress bar etc.  However, py.test would not
> > complain if it passes.  Then, for example,
> 
> -0 for not complaining when it passes
> I don't like that idea, but I also currently don't have the time to
> argue about it. twisted's trial raises an error for expected failures
> that succeed.

The "not complaining" part is not essential to me. 
We'll find a good solution i am sure.  After all one 
could specify "fixed=True", "shouldfail=True" or whatever
once the basic machinery is there to satisfy use cases.

> >    py.test --bugs=173,...,...
> >
> > would run all tests that are marked with these bug numbers
> > and turn on full traceback reporting when they fail.
> >
> > There are also other things that i'd like to tell
> > py.test about a test, e.g. having it run "boxed",
> > i.e. isolated so that it can segfault without
> > disrupting the testing process.
> 
> I would have used that a few times in the past..but I can surely live
> without such a feature.

for large projects it could evolve as being really helpful,
particularly if you can also specify platforms. 
 
> >> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
> >> the greenlets module is not installed correctly. I haven't looked into
> >> this (python setup.py install works). But I will probably have a look
> >> at it in the next days....
> >
> > cool.  You may just work in release/0.9.x or branch off from there.
> > The current way of compiling c-extension modules is a hack IIRC ...
> > mostly because i am a bit clueless on how to this correctly,
> > particularly for win32.
> 
> I thought the trick was that it automatically compiles the c modules
> on demand when it is imported?

yes - but this is not the right thing for packaged 
or setup.py installs.  One may not have write access 
to the installation path for starters.  Or no 
c-compiler is available on win32 etc. 

holger

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org