Description
With the development of Piston v3, came the package system which is built-in, allowing specific languages to be installed instead of the whole lot.
Looking back on the current solution of bash scripts building tar.gz files, then uploading them onto a GitHub release I have come to the conclusion that long-term this isn't the best route to take.
In search of a better system, I have taken a look at the viability of using nix for packages, and so far it looks pretty good.
With this switch, would mean we have to lose the piston package manager (ppman), meaning that runtime mutability of the packages would no-longer be an option; However, I haven't actually seen anyone use feature of piston before other than through the command line tool.
That being said, I want to know if this change would impact someones workflow, and would love to hear your feedback on this.
Proposal
My proposal for the new package system will utilize nix extensively, replacing the existing build.sh system with a series of .nix files.
We wouldn't lose the fine-version control that we currently have with the package build system, and I think this system would be more elegant.
We would replace the folder-per-language-per-version system with singular files retaining to the format of:
{pkgs, piston}:
piston.mkRuntime {
language = "javascript";
version = pkgs.nodejs.version;
runtime = "node";
aliases = [
"node-js"
"node-javascript"
"js"
];
run = ''
${pkgs.nodejs}/bin/node "$@"
'';
test = ''
console.log("OK")
'';
}Utilizing nix's upstream binary cache allows us to save time locally building packages, and will mean that we can have another file similar to above for node typescript without the complete re-bundling of node into typescript, saving us on space, solving the dependency problem with the current system.
By using a flake, we can allow custom packages much easier and allow for out-of-tree packages much easier.
With this, we would lose the entire /packages series of endpoints on Piston, which again I never saw much use for, other than interacting with the CLI, and will probably result in a major-version bump of the api to v3, and would mean we have to put in place a deprecation timeline for v2.
Finally, custom containers could be built much more elegantly for deployment container orchestration platforms, but at the expense of runtime environment mutability.
I would love to hear any thoughts on the above proposal before I do any major reworks.