Working with other packaging systems?

[hartzell]

I'm working on supporting/documenting packaging Go applications for Spack (RFC here).

Spack prefers to download everything on its own, which supports installations on air-gapped supercomputers, better security (though Go's language-specific system is at least as good), and etc....

Spack packages can defined "resources" that function a lot like the GH_TUPLE, identifying things that Spack should unpack and emplace in the source tree (e.g. the vendor/ subdir). E.g.

resource(name="github.com/rivo/uniseg",
         git="https://github.com/rivo/uniseg",
         commit="f699dde",
         destination=".",
         when="@2.0.3",
         placement="vendor/github.com/rivo/uniseg")

modules2tuple does all of the interesting heavy lifting I need, the only difference is how to format and print the resulting info.

I've made a rough draft of those changes, adding a couple of command line flags, making the output printing calls conditional, and adding a spack package to contain the Spack specific formatting bits.

I'm trying to figure out how to go forward. One option would be to Fork the project and head off in Spack's own direction, another would be to contribute the changes back here and maintain a merged project. Do you have any interest in the second option?

Thanks!

[dmgk]

@hartzell I'm open to pull requests but I'd like to keep an interference with existing workflow to a minimum (e.g. no additional flags should be required to generate FreeBSD-specific output etc).

[hartzell]

@dmgk -- Great! I've submitting a PR with my work in progress. I'll update it based on your feedback/preferences and based on progress on the Go packaging work.