New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot run unit tests in fresh clone #33

Closed
yanne opened this Issue Oct 7, 2011 · 4 comments

Comments

Projects
None yet
2 participants
@yanne

yanne commented Oct 7, 2011

I try to run the unit tests with paver test and 5 tests are failing due to import errors.

What is the proper command/configuration to run the tests?

@ghost ghost assigned Almad Oct 7, 2011

@Almad

This comment has been minimized.

Show comment
Hide comment
@Almad

Almad Oct 8, 2011

Member

It happens if you are using older system Paver with new devel paver.

Workaround is to paver develop new paver in your virtualenv (or to have no paver installed and use setup.py test using attached minilib).

I cannot remember a reason why this should happen thou, so I'll take a look into that.

Member

Almad commented Oct 8, 2011

It happens if you are using older system Paver with new devel paver.

Workaround is to paver develop new paver in your virtualenv (or to have no paver installed and use setup.py test using attached minilib).

I cannot remember a reason why this should happen thou, so I'll take a look into that.

@Almad

This comment has been minimized.

Show comment
Hide comment
@Almad

Almad Oct 8, 2011

Member

...but it also happens to me with older pavers as well.

Member

Almad commented Oct 8, 2011

...but it also happens to me with older pavers as well.

@Almad

This comment has been minimized.

Show comment
Hide comment
@Almad

Almad Oct 8, 2011

Member

Well, the problem is that once console_skript is invoked via paver command, your syslib's paver is used onwards, leading to further import fun.

It can be softoffixed by playing with sys.path and reload()ing paver before invoking nosetests, but it still leads to some funny consequences when some parts are seeing some versions from some paver modules. "Solution" would probably be to inspect and reload everything, but that seems rather hacky.

Rather than hacking around, I'd say I'll mention above suggestions in docs and use them.

Member

Almad commented Oct 8, 2011

Well, the problem is that once console_skript is invoked via paver command, your syslib's paver is used onwards, leading to further import fun.

It can be softoffixed by playing with sys.path and reload()ing paver before invoking nosetests, but it still leads to some funny consequences when some parts are seeing some versions from some paver modules. "Solution" would probably be to inspect and reload everything, but that seems rather hacky.

Rather than hacking around, I'd say I'll mention above suggestions in docs and use them.

@Almad Almad closed this in 31fd8ed Oct 8, 2011

@Almad

This comment has been minimized.

Show comment
Hide comment
@Almad

Almad Oct 8, 2011

Member

If anyone can find better, way, please let us know :)

Member

Almad commented Oct 8, 2011

If anyone can find better, way, please let us know :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment