build: add initial nix build system

[pauliesnug]

why?

nix is a language-agnostic build system that is purely functional; a "package" is a function which accepts inputs (src code, config, etc) and produces an output (binaries, a jarfile, documentation, anything)

one benefit of this is reproducibility. if you specify your inputs precisely, and take care not to introduce impurities, you will receive byte-for-byte, the exact output as someone else running the same function over the same inputs.

gradle is not a functional build system. oneconfig produces highly variable outputs depending on a host of impure inputs, including:

• the jvm hosting the build
• the gradle install running the build
• usage of dynamic version constraints
• snapshot dependencies
• environment vars and cli options
• artifacts cached on the system hosting the build
• gradle wrappers

by using nix we can solve these problems by using it to control the inputs we use when building polyfrost projects. this is useful for both development and packaging.

when run on oneconfig (hopefully), it will record all dependencies for both the build environment and the project, and provide a nix expression to run the build. the build itself is run in a secure sandbox, where only content-tracked network requests are allowed to fetch dependencies, and a local maven repo is created on-the-fly to host the dependency artifacts somewhere gradle can resolve them (using nix's package management)

we can use this to:

• create isolated, secure, fast, and reproducible dev envs that work anywhere
• reduce or eliminate flakiness and maintenance headaches from developers using/building polyfrost projects and CI/CD pipelines
• distribute a recipe which can reliably build a Gradle project (e.g. if we want to distribute a project on a package manager)

uninix gradle and the implementation isnt fully done yet (hence the draft) but i think this would be cool to implement in polyfrost projects.

[pauliesnug]

whu

[xtrm-en]

:+1:

[pauliesnug]

@xtrm-en thanks cutie