Open mathisrichter opened 11 months ago
Apparently, this breaks unit tests for tutorials at the moment.
I like this idea, it would make the lava user scripts much cleaner.
I would compartmentalize the structure a bit though. Could we have categories such as "neurons", "connections", "runtime", "learning", etc?
I only briefly looked into the tutorial tests but can imagine that the pkgutils-style namespace I am using could be interfering with the way the tutorial-unittests are written. I'll have a look at that later and find a fix. But I would generally also be in favor of finding a different way of testing them. Maybe in a nightly test, together with tests at scale or for demos.
I fixed all issues within this repository but the underlying approach seems to not support pulling additional imports in the lava
modules of other repositories (e.g., lava-loihi). This point was brought up by @bamsumit in our discussion and I verified that the different module init files overwrite each other. I have not yet looked into workarounds.
Yes, I definitely like this. This is like a statement that imports everything that users might want. What I was trying to say in the meeting, though, was that not everything is compatible with Loihi 2, and so this is like an environment that is for "CPU" backend. What I was aiming for was a way to have an import statement that is particular for "Loih2" backend, and so would only import the procs and configs particularly for Loihi 2 (and Loihi 2 emulation). Or similarly there could be a statement that is only for Loihi 1 or a statement that is for some other backend. But since this is formatted as a top-level import statement, its not clear how you would extend the idea to be only for a particular backend.
I fixed all issues within this repository but the underlying approach seems to not support pulling additional imports in the
lava
modules of other repositories (e.g., lava-loihi). This point was brought up by @bamsumit in our discussion and I verified that the different module init files overwrite each other. I have not yet looked into workarounds.
Why would lava-loihi or other package modify the set of things that get imported when you do import lava
? That feels very non-deterministic and weird.
If I've installed lava-dl or lava-loihi, and there are some "top-level" components that should be easy to import from those packages, let's put those things in a lava_dl.init.py or lava.dl.init.py or something like that.
Issue Number:
Objective of pull request: Imports all APIs that are relevant to users at the top Lava package level, enabling most users to write their programs with a single import statement, for example
or
The behavior is implemented in
lava/src/lava/__init__.py
. Since adding an __init__ file makes the top-level lava module a regular package rather than a namespace package, it requires adding a line from the older pkgutils-style namespace packages. This method is compatible with the implicit namespace packages we use elsewhere. If desired, the same can be done in other Lava libraries, creating the same shared folder structure Lava currently has, still distributed over multiple repositories. In those other libraries, we could then also add more imports.I am creating this as a draft PR for now to start a discussion.
See also this discussion about a flat module hierarchy.
Pull request checklist
Your PR fulfills the following requirements:
flakeheaven lint src/lava tests/
) and (bandit -r src/lava/.
) pass locallypytest
) passes locallyPull request type
Please check your PR type:What is the current behavior?
What is the new behavior?
See longer example at the top of the PR description.
Does this introduce a breaking change?
Supplemental information