The long term goal of pkg2 is the ability to automatically generate working containers with built tools from a source code repository.
Starting with a simple example. Say I want a Docker container for pkg2. How do I do that?
Regular go package.
pkg2 is a regular go module so it should install on any system with a command line go install github.com/tinyrange2/pkg2
How do I detect that automatically?
The top level go.mod is a good indicator.
Nix flake.
pkg2 also supplies a nix flake indicated by flake.nix.
This means we can just run nix run github:tinyrange/pkg2 and it will work automatically.
This doesn't include the scripts already in the repository.
pkg2 is an easy example since it's a pure Go project. You can build it with nothing but a go compiler a checkout of the source code (all you need to do is run go run . in the repo).
C/C++ is where this gets more complicated. Dependencies are only evident once the source files are parsed and the compile commands are called. Since the compile commands have so many configuration knobs and builds are so slow developers rely on build systems to create complex dependency graphs.
The theory here is combining heuristics for build system detection and our package database we can automatically infer a recipe to build a container/rootfs from a source repository. This won't work in every situation (it can't possibly) but the more instances it does work the less work package maintainers have to do by hand.
The long term goal of pkg2 is the ability to automatically generate working containers with built tools from a source code repository.
Starting with a simple example. Say I want a Docker container for
pkg2. How do I do that?pkg2is a regular go module so it should install on any system with a command linego install github.com/tinyrange2/pkg2go.modis a good indicator.pkg2also supplies a nix flake indicated byflake.nix.nix run github:tinyrange/pkg2and it will work automatically.pkg2is an easy example since it's a pure Go project. You can build it with nothing but a go compiler a checkout of the source code (all you need to do is rungo run .in the repo).C/C++ is where this gets more complicated. Dependencies are only evident once the source files are parsed and the compile commands are called. Since the compile commands have so many configuration knobs and builds are so slow developers rely on build systems to create complex dependency graphs.
The theory here is combining heuristics for build system detection and our package database we can automatically infer a recipe to build a container/rootfs from a source repository. This won't work in every situation (it can't possibly) but the more instances it does work the less work package maintainers have to do by hand.