Using plugins included with a package.

[Waylan Limberg]

The tests for my package require a custom plugin (or two) to run the
way I want them to. So I would like to ship the plugins are part of my
package. However, I'm having trouble telling nose to use the plugins
when running the tests before installing the package.

I've added my plugin as an entry_point in setup.py, but I can't seem
to get `python setup.py nosetests` to recognize the plugin and run
with it. I figured I could just include it in setup.cfg, but it
complains that it has no such option.

As a quick hack, I just added `nose.main(addplugins=MyPlugin()]` to
the bottom of my tests/__init__.py file and that works with the
`nosetests` command. However, it doesn't work when I use `setup.py
nosetests`. Note that when I say I added it, I didn't include it in
any if statement of function. It is run when the file is imported.
Really a ugly hack, but short of installing the plugin first, I don't
see how else to specify the use of my plugins.

What am I missing here?

Waylan

[Kevin Fitch]

In a similar situation we have created a runtests.py that modifies sys.path to include all the plugin eggs, then runs nose. At least that contains the hack to one spot, the only downside is that the users now need to use our script to kick off the tests instead of just doing nosetests. Although the users could install all the plugins, then run it via nosetests.

Kevin

[Kumar McMillan]

On Tue, Jun 2, 2009 at 10:40 PM, Waylan Limberg <way...@gmail.com> wrote:
>
> The tests for my package require a custom plugin (or two) to run the
> way I want them to. So I would like to ship the plugins are part of my
> package. However, I'm having trouble telling nose to use the plugins
> when running the tests before installing the package.
>
> I've added my plugin as an entry_point in setup.py, but I can't seem
> to get `python setup.py nosetests` to recognize the plugin and run
> with it. I figured I could just include it in setup.cfg, but it
> complains that it has no such option.

Does it work with just `nosetests` ? You may want to check for a
warning at the top of the output. There could have been a path
problem and if so nose will issue a warning that the plugin could not
be imported.

[jason pellerin]

On Tue, Jun 2, 2009 at 11:40 PM, Waylan Limberg <way...@gmail.com> wrote:
>
> The tests for my package require a custom plugin (or two) to run the
> way I want them to. So I would like to ship the plugins are part of my
> package. However, I'm having trouble telling nose to use the plugins
> when running the tests before installing the package.

This is an interesting use case, one that I haven't really considered.
How would you want it to work? Ideas that come to mind:

(in setup.cfg)

[nose_plugins]
name = package.module.Plugin
...

or

[nosetests]
plugin=package.module.Plugin,package.module.Plugin2

and/or

nosetests --plugin=package.module.Plugin --plugin=package.module.Plugin2 ...

nose3 (for python3 which has no setuptools) needs something like this
as well. Whatever method we come up with here ought to work there too,
if it's going to be viable.

JP

[Waylan Limberg]

On Jun 3, 10:58 am, Kevin Fitch <kfitc...@gmail.com> wrote:
> In a similar situation we have created a runtests.py that modifies sys.path
> to include all the plugin eggs, then runs nose. At least that contains the
> hack to one spot, the only downside is that the users now need to use our
> script to kick off the tests instead of just doing nosetests.

Well, that's kind of the point. I'm trying to avoid creating my own
command to run the tests.

Waylan

[Waylan Limberg]

On Jun 3, 11:58 am, jason pellerin <jpelle...@gmail.com> wrote:
> On Tue, Jun 2, 2009 at 11:40 PM, Waylan Limberg <way...@gmail.com> wrote:
>
> > The tests for my package require a custom plugin (or two) to run the
> > way I want them to. So I would like to ship the plugins are part of my
> > package. However, I'm having trouble telling nose to use the plugins
> > when running the tests before installing the package.
>
> This is an interesting use case, one that I haven't really considered.
> How would you want it to work? Ideas that come to mind:
>
> (in setup.cfg)
>
> [nose_plugins]
> name = package.module.Plugin
> ...
>
> or
>
> [nosetests]
> plugin=package.module.Plugin,package.module.Plugin2
>
> and/or
>
> nosetests --plugin=package.module.Plugin --plugin=package.module.Plugin2 ...
>

Any of those would be fine, although a setup.cfg option would be
preferable. That way I can set it and forget it. No need for me or my
users to remember to add the extra commandline options.

Actually, after submitting my initial request, I was thinking further
about it and it had occurred to me that the setup.cfg and commandline
options should provide additional ways to do the same thing as setting
the `addplugins` keyword found in `TestProgram` (and `main` and `run`
by extension). Seeing we already have the `addplugins` keyword, I
would thing the same/similar terminology would be used in setup.cfg.
So, yeah, bikeshedding aside, something like this would fit my needs
perfectly.

[Vicki]

We have a similar use case -- we're developing a test management &
reporting framework (Pandokia) with support for nose as one of its
test runners -- and I was hoping to be able to distribute the plugin
with the package and let people use it that way.

However, we would *much* prefer a setuptools-free solution. We don't
use setuptools at our site because it is overly "helpful" about
messing with the PYTHONPATH, and breaks things.

Thus of the choices given, the --plugin command line option looks like
the best choice to me.

Vicki

On Jun 3, 11:58 am, jason pellerin <jpelle...@gmail.com> wrote:

[jason pellerin]

> Any of those would be fine, although a setup.cfg option would be
> preferable. That way I can set it and forget it. No need for me or my
> users to remember to add the extra commandline options.

Agreed. Ticket is filed, but given the extent of the changes required,
I wouldn't expect this to land before 1.0 -- probably 6 months from
now.

http://code.google.com/p/python-nose/issues/detail?id=271

If that timeframe chafes anyone, I suggest cloning unstable
(http://bitbucket.org/jpellerin/nose) and getting to work. I'll
happily provide a more detailed description of how option parsing has
to change to support this in exchange for patches. :)

Until then, a custom runner script is the only way to do this, I'm afraid.

JP

[Waylan Limberg]

On Jun 3, 4:42 pm, Vicki <laid...@stsci.edu> wrote:
> However, we would *much* prefer a setuptools-free solution. We don't
> use setuptools at our site because it is overly "helpful" about
> messing with the PYTHONPATH, and breaks things.
>

I feel the same way and only moved to setuptools after failing to get
anything working without. In fact I first tried to write a custom
command with distutils. Something like:

class TestCommand(Command):
user_options = []

def initialize_options(self):
pass

def finalize_options(self):
pass

def run(self):
import nose
from path.to.plugins import MyPlugin, OtherPlugin
nose.main(addplugins=[MyPlugin(), OtherPlugin()])

setup(
...
cmdclass = {'test': TestCommand},
....
)

No matter what I did, running `python setup.py test` always ran 0
tests though. I get the feeling that the only way to get it to work
would be to write my own test loader, which seems a little much. I
guess I figured with using setuptools, this was already a solved
problem. Btw, I also tried this with setuptools and I got the same
result.

> Thus of the choices given, the --plugin command line option looks like
> the best choice to me.

Actually, running the `nosetests` command will use the `setup.cfg`
file as well (I believe if its in the same dir as nosetests is run
from), so the command line option isn't strictly needed without
setuptools. In fact, I seem to recall reading somewhere in the docs
that a few other names not related to "setup" will work for the config
file as well. Regardless, I would think we'd want the command line
option as well.

Waylan