Stance on packages using non-C native modules

[paulsnar]

As of now, most packages that I can find in the index are written either fully natively in Janet, or with C components, which then are built by jpm. But modules can be written in other languages that can compile down to a .so/.a that's suitable for linking with Janet: using bindings such as jzignet for Zig or JanetRS for Rust, it's possible, through some jumping of hoops, to create native modules that can even be used as though they were any other native module, including compiling into a static binary.

Building a non-C native module usually has extra dependencies though, such as the native language compiler and possibly the bindings (as in the case of Zig which doesn't have a package manager of its own like Rust's cargo, at least not yet), and therefore just jpm installing such modules is likely to not work if the user doesn't have the necessary ambient dependencies installed beforehand.

As such, I wanted to raise a question whether such non-C native-using packages are in scope for pkgs, given their requirement for ambient dependencies that I don't believe jpm can currently express. If so, I feel like there should also be a base expectation of jpm being able to build such a package in its entirety (e.g., via jpm build, presumably using jpm's shell fn), if the necessary dependencies are present.

[pepe]

This is a good future-oriented question, as I am not aware of any meaningful package built via other than C language bindings.

My personal view at the moment is that if it is not possible to build the package with jpm build from vanilla installation, then it doesn't belong to this registry.

But @bakpakin is the judge here as always.