We have a far more sane approach to nodeps now, which
allows us to essentially have two loggers - one that is
very useful, pretty, and clear, but requires a 'rich'
dependency, and one that is simple.
In this spirit, we factored out services/ too.
We can also set the initial console log level now when
packing the .zip.
There's still work to do with the actual flow for deps
installing / uninstalling.
But it should be far more robust now.
Finally, we have a barebones working `quartodoc`-based docs site.
It's super clever; see <https://github.com/machow/quartodoc>.
As it's "just" a quarto project with some python autodiscovery,
fleshing it out with ex. math, images, diagrams, and so forth
should be exceptionally easy.
As we develop, various linter-guided fixes are being realized.
This will be a long process, best done as we spiff everything up
in preparation for general release.
The big news is that GeoNodes Structure is now implemented,
under the new and vastly more robust chaining system.
Upload to Tidy3D cloud is tested. Next is Monitors!
We also implemented the TriMesh node, and established a strong
convention for updating nodes from sockets via. socket superclass
method. `trigger_updates`. It should be triggered as the
`update=` callback on **ALL PROPERTIES IN ALL SOCKETS**. This
method in turn calls the nodal `update()` function, which in turn
causes the node to chain-update all nodes linked to any output socket.
By default, `update()` is `pass`, so performance shouldn't be a concern,
but we should think about this deeper at some point.
Because update-chaining is done, we're ready for preview toggles on
node outputs. A lot of exciting things to do now!
We're starting to have a very advanced socket-based language
for defining nodes. It's very practical already.
The priorities are
1. All the nodes!
2. Sockets, including default values, as needed.
3. Library constants, mediums.
4. Output socket previews w/geonodes, geonodes structures.
5. Utilities including arrays (and selected array multi-input)
The code is still very spaghetti. This is very much still the
"first, make it run" part of the system design.
We're back down to a single working node, but this was a very practical
refactor.
In general, very good progress towards making #2 easy to fulfill in
its entirety.
Bugs remain:
- Category discovery has big code smells and needs smoothing. Blender
complains especially about wanting `_MT_` prefix/suffix on node
category submenu types. There's also a piece of registration logic in
category.py (big no no).
- I'd love to pass a `ruff`/`mypy` run before doubling down on node
creation, especially to help manage the complex pieces of MP logic.
- Still needs socket-bound unit-awareness feat. sympy units, before
doubling down on a data flow convention.
- Dependency management should also be smoothed out wrt. the user
experience, with cached directories exposed in addon preferences.
Solved a lot of problems related to bundled Python environment flushing
for reloading. However, we have a really solid framework for computing
node trees, and we can now both construct Tidy3D objects and noodle
them into the "Debug Printer". Next step is rote implementation of
relevant nodes, then live-visualization of the simulation setup.
See #2 for progress tracking.
