Project naming

[cefn]

It would be useful to know what the name of a project to wrap Micropython in CircuitPython-style API calls should be called.

Currently I have an mcp package (Micropython+CircuitPython) largely thanks to Tron (see e.g. https://www.youtube.com/watch?v=SmXt6Q6jU_Y + https://youtu.be/AvayPCoHGFE?t=26s ) which can be a place to hide wrapper/port specific stuff.

However, it would be useful to know what the Long and Short project name should be, as it will creep into repositories and package names which are inevitably visible and needing to be managed when people put packages onto Micropython boards.

[ladyada]

i think 'blinka' is a fine project name because its overall neutral, and doesn't mean/stand for anything. is that your q?

[cefn]

OK, so any packages specific to the port will be rooted at blinka.x.y.

It would make sense to migrate stuff like https://github.com/cefn/Adafruit_Micropython_Blinka/blob/master/python/board/feather_huzzah.py under blinka/feather_huzzah/board/init.py so that all feather_huzzah-specific stuff can be kept in one (removable/includable) place.

[ladyada]

OK :) whatever makes you feel good about the structure! esp/pyb are fairly fast chips, so they can deal with layers of abstraction

[tannewt]

Having a top level blinka package won't affect the ability to import board directly, right? If we're forced to have a top level I'd be tempted to introduce a circuitpython package and having everything move under it. Our existing top levels shouldn't conflict with anything now though so I don't think its required.

I want to ensure that our imports we describe in learn guides work as documented after the blinka library is installed.

[cefn]

Main intent is consistency esp. with other adafruit projects so I am not confusing other adopters/contributors, and future maintainability of bundles targeting different platforms.

In conclusion based on the cookiecutter approach and given the naming choice I should have a python path rooted at /blinka so there will be a /blinka/blinka/init.py to place wrapper-specific stuff imported as blinka, and /blinka/digitalio.py would be imported as digitalio

Then all stuff for a specific board would be in the repo at /blinka/blinka/board/NAME/*.py, imported at blinka.board.name. This should be a package not a module so that hardware-specific elements can be selectively included to save on RAM/flash storage (e.g. if you only trigger the platform-introspection logic of digitalio, then you won't have loaded all the platform-specific elements for bitbangio).

Alongside /blinka, I can have separate files and folders for documentation, integration testing and other stuff which isn't intended to be part of the distribution ending up on boards.

Thanks. It's pretty useful to get it right now, so that there isn't a lot of rework later on. Also means I can confidently raise a PR soon without corrupting the main repo with wrong-headed paths.

[cefn]

@tannewt the blinka package is just a place to put stuff which is imported by the blinka-specific implementations of e.g. board or digitalio which indeed should be addressable exactly as if they were built-in packages on a board running a CircuitPython image. Does that answer your q?

[tannewt]

Yup! Works for me. Thanks!