It would be awesome to have a mechanism to reuse code by being able to include a ‘pattern’ (or file, or library or how ever it would get labeled in the editor) in another pattern.
As mentioned in my post text rendering it would be fantastic to include this functionality in other patterns without having to copy/paste the entire thing. There are also things I’ve been doing around WebSockets that would be cool to place in a library for consistency across multiple patterns.
I think a very basic version of this could be accomplished fairly cleanly copying C-style #include that would simple inline the referenced pattern. Something like include('matrix-text') and if that pattern exists it would be inlined in the underlying compilation step.
A more advanced version could even adhere to using only variables and functions with export but that’s by no means necessary for use cases I have in mind.
I tend to err on side of user responsibility, ie; this pattern requires this library but understand that’s a dangerous path towards writing a package manager.
Another simpler solution could be to include the inlined code when exported, this could also be optional, something like package pattern vs export pattern.
I grab the .epe of your cool new pattern
You used a few includes. But the .epe just includes it all as one file.
I grab the new .epe of your 2nd new pattern…
But the libraries are included in that too, so. Why exactly do we have includes if they aren’t going to be used?
So we need multi files in order to make this work… So the epe builder/decryption needs to do it.
Portability / ease of use is top priority, and is the main hurdle to adding a feature like this.
I would like to add multiple files/tabs to a pattern (even resources!), and from there you can import to your main pattern, much like you might in a JS project. import {blarp, fizz} from 'some/path'. You would need to be able to export “the pattern” not just the main source file, and likewise import it. The .epe files are like tarballs (or perhaps APKs) of the whole project, dependencies and all.
Perhaps once that exists, a compromise would be to effectively replace one or more of those paths/files with a symlink to another pattern. Exporting would resolve/follow those links and export the bundle, and would likewise import a single flat pattern, which you could replace those with symlinks if you wanted to point to library patterns you already installed.
I’m still kind of against complicating the library/file system setup on the current hardware platforms. There’s not really a lot of room in there as it is, and these devices weren’t designed with constant large (relatively) scale file system activity in mind. The ESP32 in particular – the file system still seems cranky to me. It still occasionally eats patterns if I’m not super watchful about doing absolutely nothing while it’s saving. Happens more often with CPU intensive patterns and as available storage gets lower.
The NVIDIA Jetson-based Pixelblaze, of course, will be a different story.
What I would like though, is a programmatic way to move patterns on and off the Pixelblaze. I’ve got a lot of patterns, and a lot of Pixelblazes, and keeping track of who has what version of a pattern is becoming tougher. With an API, I can build a tool to keep things backed up to Github and in sync.
It’ll partially solve the library thing too, because you could keep libraries on your computer, and automatically grab and merge things into a final pattern before uploading to the Pixelblaze. No size advantage on the PB, of course, but it could save some of the headache of maintaining code that’s duplicated across multiple patterns.
