Makes sense, looks good!

@andrewleech @stinos I have updated this in a way that keeps it minimal for non-unix ports, but makes it possible to retain the full discovery functionality for unix/windows.

I've also (I think) addressed @stinos's fixes from #526 and some other bugs too.

The basic idea is that for non-unix ports, you can either:

• Copy the test script to the board and run >>> unittest.main("test_foo.py") or >>> import test_foo; unittest.main(test_foo)
• Run the test script via mpremote run test_foo.py, assuming it has a call to if __name__=="__main__": unittest.main() at the end.
  (I lost track a bit, but I think both of these use cases were currently broken)

On unix, you can run a test script directly

• micropython test_foo.py (assuming unittest is available in path or frozen)

Or you can optionally install unittest-discover in which case you can do

• micropython -m unittest or micropython -m unittest discover --args to do discovery.
• micropython -m unitest [modulename or filename]* to run individual modules or files.

Practically what this means is you can either require("unittest") or require("unittest-discover") (the latter includes the former), and soon upip.install() either.

We're introducing a new convention here that a micropython-lib module with a hyphen is an extension to another module. This will replace the options feature that was previously only used by aioble, and I plan to split aioble into aioble-core, aioble-peripheral, aioble-central, etc and then have an aioble that requires the default set.

Two other notes:

• unittest_discover doesn't work on unix-standard (fnmatch needs re.sub). See unix: Refactor variant config and enable features in standard build. micropython#9060 to address this.
• There's no way to invoke discover on non-unix (simply because there's no entry point that isn't via __main__). I don't think this exists in CPython either? We could provide some sort of convenience wrapper, but it would be non-standard, unless we provided TestLoader.discover(). I guess in theory you could construct sys.argv and call unittest.main() though?

In case you hadn't seen the link @jimmo there was another discussion thread at https://github.com/micropython/micropython-lib/pull/488/files#r963787097 which wasn't entirely resolved either...

We're introducing a new convention here that a micropython-lib module with a hyphen is an extension to another module. This will replace the options feature that was previously only used by aioble, and I plan to split aioble into aioble-core, aioble-peripheral, aioble-central, etc and then have an aioble that requires the default set.

Hmm... I'm not entirely convinced on hypen-as-extension; in the micropython packaging world the hyphen is standard/expected replacement for underscore in the package name. Overloading that here is likely to be confusing I feel.

The . is already the standard for extending packages... if they're intended to install into the same namespace then that should be the way it works. If instead they all install into separate folders / files that need to be supported / imported by the base package (needing a list of try/import/except?) then that's a new pattern that possibly needs some more thought... or maybe not as it's basic standard python at that point that doesn't really even need a convention.

I personally like the options system, it's very powerful while still being quite readable (so far).

In case you hadn't seen the link @jimmo there was another discussion thread at https://github.com/micropython/micropython-lib/pull/488/files#r963787097 which wasn't entirely resolved either...

Yes I did see that. I think this PR sorts out the issues raised there (and in the other PRs).

The . is already the standard for extending packages...

Where is that standard? I don't think I've ever seen a real pypi package with a "." in the name.

The idea here is that unittest-discover is an "extension" for unittest. The hyphen was chosen because if it were an underscore then it would appear like the name of an actual importable module. This isn't uncommon on pypi i.e. foo-bar adds optional bar functionality for foo.

That said, there isn't really a great precedent from Python where the extension packages directly modify the behaviour of an existing package. One example is when you use extras_require, which allows you to bring in extra dependencies (which may result in a library directly gaining extra features). So you'd have aioble[server] but server still needs to resolve into a package that can be installed (i.e. aioble-server).

I personally like the options system, it's very powerful while still being quite readable (so far).

Me too. I thought it was a neat way to make freezing simpler. But it doesn't work for installable packages, only for manifests.

Me too. I thought it was a neat way to make freezing simpler. But it doesn't work for installable packages, only for manifests.

I kind of through the syntax aioble[server] should be parsable by upip to install options? I guess that doesn't cover turning off options that are on be default.

Where is that standard? I don't think I've ever seen a real pypi package with a "." in the name.

Good point... I was thinking of namespace packages but no, they don't put . in the name, they just install into a "shared" package folder.

I didn't test everything, but the core issue is still there: when passing a module to unittest.main() it gets ignored when the unittest_discover module is installed. The logic I added ('if module passed to main then skip discovery and just use that module') should remain intact (also for CPython-compatibility), and I'd expand that to 'if module passed to main then don't even try to import unittest_discover'

Replacing \ with / in _dirname_filename_no_ext is missing so paths with backslashes will be treated differently.

Thanks @stinos !

Replacing \ with / in _dirname_filename_no_ext is missing so paths with backslashes will be treated differently.

I misunderstood what your change was doing here. Or perhaps I don't understand how paths work on Windows and how they interact with sys.path?

When the user does

$ micropython -m unittest windows\path\to\foo.py

then should "windows\path\to" should be added to sys.path, followed by import foo? Or should we be adding "windows/path/to" to sys.path?

I've changed it to the latter because it sounds from your comment like that's what it should be.

when passing a module to unittest.main() it gets ignored when the unittest_discover module is installed.

Ah yes, of course. I've fixed this such that unittest.main() never uses discover. You now only get discover via __name__=="__main__".

then should "windows\path\to" should be added to sys.path, followed by import foo? Or should we be adding "windows/path/to" to sys.path?

Ah, that doesn't actually matter, both should be handled fine, the issue is that _dirname_filename_no_ext('path\to\foo.py') yields ('', 'path\to\foo') because it tries to split on / not \. So it just adds an empty directory to sys.path.

Ah, that doesn't actually matter, both should be handled fine, the issue is that _dirname_filename_no_ext('path\to\foo.py') yields ('', 'path\to\foo') because it tries to split on / not \. So it just adds an empty directory to sys.path.

Oh!! I thought i was explicitly handling that by using os.sep. That was the whole point of why I changed that. But now I see that on the Windows port, os.sep is stil /. That needs to be fixed in the Windows port right?

Updated to just use the replacement, with a comment explaining why. We should implement sep correctly for Windows, as well as altsep on Unix/Windows, and can fix this when that's done.

Ok thanks, this works fine now for everything I tried with it.

Thanks! Merged in 796a598