depend on other custompios modules

[jeffeb3]

I want to make an octopi with auto-wifi-hotspot and also cnc.js. I think I'm getting there after editing the octopi repo, but I think it would be cleaner if I could define two locations for modules, then I could have my own repo next to octopi.

so my config would look something like this:

export MODULES="base(raspicam, network, node.js, disable-services(octopi, cnc.js, auto-hotspot), password-for-sudo)"

I'm really loving working on this, btw. I'll have to write the node.js and cnc.js modules. It's very well thought out.

[guysoft]

Hey, Thats cool and was not requested so far. I was thinking of adding in the long run a modules directory, but never got to implementing it (PRs are welcome, I can point to where this should go).

Untill now all requests were supplied by the variants module.

I can accept pull requests to the CustomPiOS repo if its something that benefits others.

BTW, I don't think modules with dots will work, because the config variables are resolved by that name.

[jeffeb3]

BTW, I don't think modules with dots will work, because the config variables are resolved by that name.

Aha! That explains it.

I was thinking of adding in the long run a modules directory, but never got to implementing it (PRs are welcome, I can point to where this should go).

I am not the best with bash, but I see that the modules gets expanded once for the config (in src/config), and then again in the execution_order.py script. I don't think it would be too hard to add a custom location to this, but the real work is in getting this set by the user.

I wonder if it makes sense to organize octopi as something that can be checked out in CustomPiOS/src/modules/ as a submodule?

By their nature, it will be tough to make truly generic modules. I'm finding out, for example that I want to leverage the haproxy setup you have in octopi to load cnc.js as a different backend, and a simple splat page as the default backend, so I'm going to have to depend on the octopi module, but modify it's files in place. It is going to get a little hairy.

[guysoft]

execution_order.py is python3 and is where the module selection is going on. Its already favoring modules in the dist folder over the ones in CustomPiOS. I think all you need is to add more module folders, that should be easy (the list order dictates priority): https://github.com/guysoft/CustomPiOS/blob/CustomPiOS/src/execution_order.py#L8

I am just not sure how to give the user the option to decide on which paths have modules in them. Perhaps a "cache" folder in the dist, and have modules starting with http:///https:// resolved as "net" modules, and download them from github/zips of git repos.

[jeffeb3]

So, I cheated, and just included CustomPiOS and Octopi as git submodules:

https://github.com/jeffeb3/v1pi/tree/master/dependencies

I don't have the perfect git foo to only pull out the src/modules/octopi from OctoPi, but it's working well, and I can control which versions are tied to my particular image.

Sidebar: I am still working on the image, but I have something working. Thanks a bunch for your CustomPiOS and Octopi work. I don't want to offend you, so if there's anything where I'm not giving enough credit or I'm accidentally pointing users to the wrong place, I'm happy to hear about it.

[guysoft]

I am not sure I understand how the submodule helps you. But if it works for you and you are able to maintain against the latest code then great. It does make me want to get the net nodules working. I had a few ideas. For example you a possible syntax could be to write: MODULES="disable-serivces(octopi:https://github.com/guysoft/OctoPi.git), auto-hostpot" or MODULES="disable-serivces(octopi:https://github.com/guysoft/OctoPi/archive/0.14.0.zip), auto-hostpot" And all modules from git/zip repo located in src/modules would be able to be imported in to a distro.

cc @foosel

[jeffeb3]

I keep thinking about the way custompios and the images are organized, and I keep thinking what makes more sense is running the toplevel command from inside custompios, with a pointer to the workspace of the image. So:

cd CustomPiOS/src
./docker/build_dist ~/octopi/src # or ./vagrant/build_dist or ./native/build_dist or ./windows/build_dist

All the build commands would be up to date with a git pull in CustomPiOS and with this github module thing, you could make your image folder really light (the config file, basically). No need for make_custompi_os or update-custompios-paths

[guysoft]

@jeffeb3 Yes I guess that makes sense. When I started CustomPiOS the distro was in the center. I wanted people to get the distro running and then manage that. But your point does make sense.

You will however need a "deploy vagrant vm" or docker build (in the works) for those build methods to work.

[guysoft]

This might be easier now if you use the docker build method, you could create a docker-compose.yml that mounts a module from another distro in to the custompios module folder directly, sort of like a symlink,. Or even have it work as an automated build.

[guysoft]

Closing if no reply

[jeffeb3]

Yeah, sorry. I have been using the git submosules and I've been happy with it. I check out octopi and custompios as submodules in my repo and I then have a simlink to the octoprint module in my modules folder. I can precisely control the commit I am using.

The other problem is that I understand this really well when I am using it, and then I leave it alone for 6 months and when I come back, I've forgotten most of it.