Allow custom footprints to be passed in via cli - #64
#64Allow custom footprints to be passed in via cli#64chrishoage wants to merge 1 commit into
Conversation
|
I actually ended up refactoring a lot of the cli in order to get a watch mode for the output so I could develop the board using the still in development v4 Not sure if you'd want me to open an PR, but if so just let me know. https://github.com/chrishoage/spleeb/blob/main/scripts/cli.js |
|
Thanks for both of these! Footprints are under heavy refactoring at the moment, but afterwards I was already planning to support this (mostly with zip packages, but no reason why a separate footprint folder can't work). And watch functionality would be convenient, too. So, might not merge as-is, but these are good as drafts + reminders, and I'll be sure to get to them after the refactor phase is done. Tyty! 👍 |
I'd def like to see a footprint folder since it would be a lot more "git friendly" than a zip file. Though I can see a zip being useful for people to include collections of footprints if they are not using git / making their own footprints.
Feel free to close this if you'd like to reduce the noise in the repo. I just did this so I could have an easier time developing the board. Thanks for the wonderful work on this project! |
Oh sure, the "official" footprints will be in a folder, and "3rd party" ones can be then mixed and matched by adding their folder(s). I just mention zips as a way to allow self-contained, dependency-less packages that use custom footprints or whatnot. Also, zips are probably gonna be the more common usage as they'll be the easy way to add extra stuff (either a self-contained config, or just a bunch of footprints usable from the config) to the web ui - like you said, CLI is probably more of a power user feature.
Oh no, no, it's good to have an active reminder. I must learn to thrive amid the chaos anyway 😆 Anyhow, I'm just glad my shit's turning out to be useful... |
|
Just a quick update that footprint sideloading has already landed in |
Many people fork ergogen in order to add custom footprints. This is a little cumbersome and since there is already a way to inject footprints at runtime I have exposed this feature.
Please let me know if there are any other improvements you would like me to make before merging, as I do realize my implementation is a little naive (though my position is the CLI is a power user feature, and custom footprints double so. I saw it as "use at your own risk" sort of thing.
Example of use:
This allows, for example, a user to load a reversible promicro footprint, or any other custom footprint they wish. Users can depend on
ergodashin their package.json for their project, then load footprints from their repo with out any need to fork (if all they wish is to load custom footprints)