CCEmuX is a great emulator as we know it, but as someone who had to keep moving the files to test the programs, it was a bit uncomfortable. But out of the necessity comes the solution, and I came up with...
The concept is pretty simple: I have a folder which I want to be my environment. Well, I set up this folder as an environment called "my-project" and run it. And how is this done, you say?
$ ccrunx configure my-project
$ ccrunx run my-project
Yeah, that's it, run that in a folder which has a subfolder called "my-project" and you're good to go, but functionality doesn't end here. You can create new IDs with "ccrunx n <id>", and using "ccrunx a <project> <folder>", you can attach the contents of <folder> into the container regardless of emptying it.
The code is here: https://github.com/daelvn/ccrunx
And you can install it via LuaRocks: "luarocks install ccrunx"
Now the problem lied in sharing all of this with someone else for debugging purposes, help, code sharing, releasing... anything. I immediately thought of LÖVE: their .love files are just structured .zips, so that is exactly what the next tool does:
It has a really simple usage, go on a folder that has a subfolder configured, and run:
$ ccrunx-image compress my-project
$ ccrunx-image decompress ccrunx-image_my-project.ccrunx
Do the first command to generate the .ccrunx file and the second to open it: They alias to "ccrunx-image c" and "ccrunx-image d". It only depends on argparse and ltext.
The code is here: https://github.com/daelvn/ccrunx-image
And you can install it via LuaRocks: "luarocks install ccrunx-image"
Now, what if I have three of my containers, they're different development places, but I need to test them all together. This should be pretty obvious, when you think of containers you should think of Docker, and this next tool is just "docker-compose" but for CCRunX.
The usage is rather simple, and to be fair, the configuration is, too, just not as simple as the others. This all is best understood with a practical example. Let's invent three programs, call them "paboot", "paunify" and "paxcomp", and extra files called "paunify-config". Pretty realistic, huh? Let's configure them all:
paboot paunify paxcomp paunify-config
$ ccrunx c paboot
$ ccrunx c paunify
$ ccrunx c paxcomp
$ ccrunx c paunify-config
# Although paunify-config will never be run, configuring it will allow us to place the files inside
# anywhere we desire.
Now, let's attach paunify-config to paunify:
$ ccrunx a paunify paunify-config
And that's how we get our base ready, we don't need to run them right now, they already configured themselves.
This is the "hardest" part, we have to create our ccrunx-compose.yml file (à la Docker!), and below will be two examples: the first valid for our example, and the second explaining all the capabilities of the YAML file:
For our example:
name: Pantheon Bootloader
name: Pantheon XCompiler
id: 1 # For some reason, we want this on computer with ID 1, we just do.
after: moonc ? # Turns out this was written in MoonScript! This should compile it for us.
name: Pantheon Unificated libraries
path: /etc/paunify/ # This is inside the container
name: description or extended name
path: where to place the files
after: run a command after it's placed
name: it can decompress images too
# Set startup files for computers
Now we just have to run "ccrunx-compose build [project]" (project is optional, it is "compose" by default, that's why our YAML file starts with "compose:") and the container will be created. To run it, you can either do it the ugly way "ccrunx r compose" or "ccrunx r project", or you can just "ccrunx-compose up" or "ccrunx-compose up project".
The code is here: https://github.com/daelvn/ccrunx-compose
And you can install it via LuaRocks: "luarocks install ccrunx-compose"
That's all for CCRunX, it wouldn't have happened without CCEmuX, so big kudos to the CCEmuX team: drmarcuse, Lignum, Squid and Lemmmy! (i mean, primarily). Be sure to report any issues you might find!