This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: load_tests chaining into discover from non-discover entry point gets top_level_dir wrong
Type: Stage: test needed
Components: Tests Versions: Python 3.5
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: r.david.murray, rbcollins
Priority: normal Keywords:

Created on 2014-10-30 03:13 by rbcollins, last changed 2022-04-11 14:58 by admin.

Messages (2)
msg230253 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2014-10-30 03:13
The following trivial chain-into-discover load_tests:
def load_tests(loader, tests, pattern):
    import os.path
    # top level directory cached on loader instance
    this_dir = os.path.dirname(__file__)
    return, pattern=pattern)

Will work fine when that module was loaded by discover in the first place, but if the entry point was e.g. loader.loadTestsFromModule then it will fail because _top_level_dir starts None and is, if not supplied, inferred from start_dir.

One possible way to improve this would be to check for start_dir being a child of rather than just an exact match of, the elements of sys.path. This isn't complete of course, because individual packages can have their own path. And we also compare with top_level_dir to assess importability - but perhaps we can deprecate/ get rid of the top_level_dir concept entirely - it only has two functional uses: a) making it possible to import things when the path to be discovered isn't on sys.path yet, which could be done by the unittest front end, leaving the core API less complicated, and b) to map from paths back to modules which is complicated by the need to handle namespaces and other packages with multiple directories providing modules. (Because load_tests can chain into other directories that aren't under top_level_dir this same bug can show up in the inverse situation).

Another possibility would be to make a new api 'discover from a package' and split discover's internals into 'find packages' and then a chain call to this new api. I'm in favour of this latter approach because I think it will have less compromises and work better. It might also make it easier for us in fixing the rather ugly thing at the moment where discover('') adds to sys.path before figuring out that its a module dotted path, not a filesystem path.
msg230268 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-10-30 13:02
+1 on the refactoring.  I think it makes more conceptual sense.
Date User Action Args
2022-04-11 14:58:09adminsetgithub: 66952
2014-11-01 01:32:48terry.reedysetstage: test needed
components: + Tests
versions: + Python 3.5
2014-10-30 13:02:38r.david.murraysetnosy: + r.david.murray
messages: + msg230268
2014-10-30 03:13:07rbcollinscreate