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.

Author rbcollins
Recipients Claudiu.Popa, Florian.Apolloner, ashkop, eric.snow, ezio.melotti, michael.foord, rbcollins
Date 2015-04-20.07:51:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1429516302.35.0.0927084764288.issue23882@psf.upfronthosting.co.za>
In-reply-to
Content
Ok, so here's whats happening:
the default behaviour is to do discovery of '.', which bypasses the namespace support code.

Running with tests as the first parameter works because it doesn't require the directory being directly scanned to be a package.

Equally, if the namespace isn't mapped to a local directory, 'python -m unittest tests' will load tests from the tests namespace.

So - this seems to be acting as designed. Namespace packages working fine.

However, I think what you're asking for is that namespace packages in your cwd are picked up and tested, without you having to supply the namespace name?

I think what we'd need for that to work sanely is a patch to teach loader.discover to determine the local namespaces which are present under start_dir. Right now this code:
        elif os.path.isdir(full_path):
            if (not namespace and
                not os.path.isfile(os.path.join(full_path, '__init__.py'))):
                return None, False

gets in your way: we assume that either we're processing a namespace, or there are no namespaces at all.

I think some more detangling of the generator could address this fairly cleanly.
History
Date User Action Args
2015-04-20 07:51:42rbcollinssetrecipients: + rbcollins, ezio.melotti, michael.foord, Claudiu.Popa, eric.snow, Florian.Apolloner, ashkop
2015-04-20 07:51:42rbcollinssetmessageid: <1429516302.35.0.0927084764288.issue23882@psf.upfronthosting.co.za>
2015-04-20 07:51:42rbcollinslinkissue23882 messages
2015-04-20 07:51:42rbcollinscreate