aptly VS nickel

You should ask in the upstream bug tracker (is it this one? https://github.com/lubomir-brindza/nautilus-typeahead). First step is to get it to build for Debian manually/locally - i.e. patch the official nautilus Debian package. Then it's easy to setup a personal APT repository with aptly

Exactly what aptly is for. No idea about CentOS side, for that we just had rsync from official repo + some scripts

I'm not sure if this is an option, because it might break the isolation model, but you could setup repo mirrors in whatever tool of choice you like, but for Debian/Ubuntu, I think aptly is really featureful.

I know that it is not directly what you asked about, but without knowing how the signed debs are being used, I can say that if you were to use aptly to create an apt repo to house your debs to then be installed on whatever machines offline (assuming network connectivity, which may be an incorrect assumption), it requires you to sign a published repo/mirror, and also requires you to install and trust the key on any systems that you then want to use to install package unless you specifically use [trusted=yes] in the apt repo list file.

There's also Aptly but I've never used it. Looks neat, though.

I personally just mirror the packages for what ever I'm using with aptly and use the netinstall iso and point it to that local mirror. The netinstall iso will pull any needed updated from the repo.

Take a look at Aptly.

Aptly is a purpose-built DEB content management solution. Never used but I've heard good things.

The last time I got involved in repo/package management, we used aptly Later moved to Jfrog artifactory. The latter is very expensive.There is also pulp some said it is good, which I personally never managed in production environment, so I can't recommend for or against.

So, its key features are:

1. domain-specific: designed for conveniently creating and composing derivations. This reason alone already justifies a new language, or an embedded domain-specific language (such as the Guile/Scheme for guix), or a mix of both (Starlark, the build language of Bazel embedded in a restricted Python-variant).

2. purely functional: this ties well into the philosophical backing of Nix the package manager, which aims to be purely functional, also known as hermeticity in other build systems (Bazel).

3. lazily evaluated: similar to other build systems (including Bazel), so that you can build only what you need on demand.

4. dynamically typed: this one is controversial. Being dynamically typed—in other words, not developing a type system—gets Nix out of the door first. But users often complain about the lack of proper types and modularity. There are experiments to address this, such as Nickel (https://github.com/tweag/nickel).

It is understandable that a one-pager may not have space for the whys.

Nickel：Nickel is a straightforward configuration language aimed at automatically generating static configuration files. Essentially, it's akin to JSON with the addition of functions and types.

Also look at nickel which is an evolution of nix. It's my favorite in this space.

nickel-lang.org

https://github.com/tweag/nickel

Or this https://github.com/tweag/nickel

Nickel is a programming language. While HCL is just a configuration format, so not really comparable.

Here's a comparison with similar tools: https://github.com/tweag/nickel#comparison

As for 'providence', I suppose you meant provenance :) it's been delayed because this was less critical for 1.0 to decide on or to implement (as it: it doesn't break backward compatibility in any way to add this feature in the short term), but this is very much on the roadmap: Issue #235. That's a must-have in a language with merging like Nickel.

Have you considered using a different language for templating? this could be a BIG selling point. Some good ones are cue-lang (though I haven't seen support for rust), kcl or nickel-lang.