| Summary: | dev-python/formencode fails tests | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | bugs, dustin |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | [IR] | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Build log | ||
|
Description
Diego Elio Pettenò (RETIRED)
2009-11-27 13:23:33 UTC
Created attachment 211327 [details]
Build log
I can't reproduce this bug with Python 2.6 and 2.7. Cannot reproduce either. Looks PYTHONPATH releated? Johan can you explain that further? What about PYTHONPATH? Diego: Sorry, completely forgot to revisit the ticket. What I meant was that nose perhaps messed up the import phase. Does this also happen if you run [the same version of] nosetests manually? If so, what does nosetests --verbosity=<something high> say? I've tried every version of nose in portage with no luck. Syntax indicates you at least run nose-0.11.0. If it runs clean I've pretty much got no clue :( testing it manually is a bit tricky given this is out of the tinderbox… Maybe python team can increase the verbosity a notch? (In reply to comment #6) > Maybe python team can increase the verbosity a notch? You can pass e.g. --verbosity=4 to nosetests (default verbosity is 1). (In reply to comment #6) > testing it manually is a bit tricky given this is out of the tinderbox… > > Maybe python team can increase the verbosity a notch? > You can put configuration in a .noserc, see nosetests manpage line 58 and forward. Does this work for you? Diego: I've been looking at your other tickets and I'm starting to believe that something is fishy with your setup. Unfortunately I can't give any pointers as to what it may be, but perhaps the more verbose nosetests can give a hint as to why the imports are failing. I suspect this has something to do with the complex inter-package dependencies (basically, non-blank __init__.py's) in FormEncode. This can lead to situations where the order that imports are performed can lead to blank module objects. For example: from formencode import schema can mean to load the schema module from the formencode package, or to load the symbol "schema" from the formencode module. If sys.modules['formencode'] already exists, I think Python will assume the latter and fail. Another possibility is that one of the several conditional imports in the package is failing but eating the ImportError. This would make the most sense in the tinderbox, where only the DEPENDS packages are available. That said, I also can't get this to fail, even when adding unnecessary imports. Dustin, you might be on the right track on the conditionality of dependencies but it is important for you to change one idea in your assumptions ;) _My_ tinderbox does not have only the DEPEND packages; it actually has *as many packages in the tree as possible*. So it might well be that it is failing something because it's importing something that is passing for something else, or there's a conditional import that is only triggered when a package not in the dependency tree is present. Dustin, the ebuild for formencode 1.2.2 specifically sets the ebuild to the formencode build directory. This will then always have precedence over site-packages. I'm starting to believe that something else is interfering just as Diego states. Diego: If you have the time, please run nosetests with lots of verbosity - should show imports and possibly give us hints. Formencode is nowadays at 1.2.4. Does this still occur? Closing with NEEDINFO. Please run a test with the newest version and report back if you have any issues. |