dloreto

I have a similar view to yours: as soon as you need variables, imports, functions or any other type of logic ... the existing "data-only" formats break down. Over time people either invent new configuration languages that enable logic (i.e. cue or jsonnet), or they try to bolt-in some limited version of these primitives into their configuration.

My personal take is that at some point you are better of just using a full programming langugage like TypeScript. We created TySON https://github.com/jetpack-io/tyson to experiment with that idea.

JSON + types + functions using TypeScript syntax. Makes it possible to use TypeScript as a configuration language for applications written in `go`, and soon `rust` and other major languages.

A follow up:

1. We've now implemented pretty thorough testing: https://github.com/jetpack-io/typeid-go/blob/main/typeid_tes...

2. I clarified the prefix in the spec

Thanks for the feedback!

We've now implemented pretty thorough testing: https://github.com/jetpack-io/typeid-go/blob/main/typeid_tes...

Thanks for the feedback!

I hear you ... and I debated using either base58 or base64url. I do like the more compact encoding they provide.

Ultimately I ended up leaning towards a base32 encoding, because I didn't want to pre-suppose case sensitivity. For example, you might want to use the id as a filename, and you might be in an environment where you're stuck with a case insensitive filesystem.

Note that TypeID is using the Crockford alphabet and always in lowercase – *not* the full rules of Crockford's encoding. There's no hyphens allowed in TypeIDs, nor multiple encodings of the same ID with different variations of the ambiguous characters.

Thanks for the feedback!

We have tests for the base32 encoding which is the most complicated part of the implementation (https://github.com/jetpack-io/typeid-go/blob/main/base32/bas...) but your point stands. We'll add a more rigorous test suite (particularly as the number of implementations across different languages grows, and we want to make sure all the implementations are compatible with each other)

Re: prefix, is the concern that I haven't defined the allowed character set as part of the spec?

The checksum idea is interesting. I'm considering whether it makes sense to add it as part of the TypeID spec.

The CLI tool will support encoding/decoding any valid UUID, whether v1, v4, or v7. We picked v7 as the definition of the spec, because we need to choose one of them when generating a new random ID, and our opinion is that by default, that should be v7.

We might add a warning in the future if you decode/encode something that is not v7, but if it suits your use-case to encode UUIDv4 in this way, go for it. Just keep in mind that you'll lose the locality property.

It's based on UUIDv7 (in fact, a TypeID can be decoded into an UUIDv7). The main reasons to use TypeID over "raw" UUIDv7 are: 1) For the type safety, and 2) for the more compact string encoding.

If you don't need either of those, then UUIDv7 is the right choice.

That's how the type is encoded as a string, but type-safety ultimately comes from how the TypeID libraries allow you to validate that the type is correct.

For example, the PostgresSQL implementation of TypeID, would let you use a "domain type" to define a typeid subtype. Thus ensuring that the database itself always checks the validity of the type prefix. An example is here: https://github.com/jetpack-io/typeid-sql/blob/main/example/e...

In go, we're considering it making it easy to define a new Go type, that enforces a particular type prefix. If you can do that, then the Go type system would enforce you are passing the correct type of id.

The stated downsides come from poor data locality when using mostly random UUIDs; but you can keep most of the benefits of a globally unique identifier, and retain locality, by using UUIDv7.

At jetpack.io we've been doing exactly that via TypeIDs: https://github.com/jetpack-io/typeid and there's a PostgresSQL implementation available. TypeIDs are UUIDv7 with additional type information, so you also get type-safety in your IDs.

Tools like Devbox: https://github.com/jetpack-io/devbox are making this way easier. Devbox is powered by nix, but it hides all of the complexity and makes it easier to use.

Depending on your use case, devbox (https://github.com/jetpack-io/devbox) could be what you're looking for. It is powered by Nix, but abstracts the nix language away, so that you can use it like a "regular" package manager.

Currently it works on a "per-project" basis, but we're planning to add support to use it as your primary package manager for global installs as well.

The latest version of devbox allows pinning the sha of the nixpkgs repository to whatever you want. We don't yet allow pinning on a per-package basis within nixpkgs, but we're working on that.

Haven’t tried that yet. We started with using Docker directly because we were very familiar with it, and thought users might want to “preview” a dockerfile before asking devbox to build a container (we don’t have that yet, but can easily add it)

That said, I do want to experiment with building the container directly through nix and seeing if there’s advantages to doing that. I just haven’t had the time yet.

The initial shell is slow: nix reinstalls a bunch of stuff the first time it runs. We’re planning to add a progress bar that makes that clear.

Sorry for the hiccups – it is our first pre release version but feedback like yours helps us harden it. It should definitely be considered beta software right now, but we’ll have it hardened before announcing a GA/1.0 version

It's likely you have not installed the pre-requisites: namely nix. Without nix, it can't find the package.

That said, we'll improve the error message so that when nix is not installed it tells you you should install it.

Totally fair.

A clarification: the config file is currently exposed as plain JSON file. Cue is used internally because we use it to validate the schema after the JSON is parsed – but currently not exposed to users.

The dependency on Docker only exists for when you want to turn your shell into a container – but it's not otherwise used when you're just running a shell locally.

When writing javascript there's often a desire to have "isomorphic" or "universal" applications. Write the code once and run it in _either_ the client or the _server_.

Devbox is taking a similar approach to the development environment: declare it once, run it locally as a shell, and when you're ready, turn it into a container without having to re-declare it. It's only the latter functionality that has a Docker dependency.

Yes, we use it internally for all of our development and plan to continue actively maintaining it. If there's enough interest from the community we would love to make it a Cloud Native Computing Foundation project.

Yes, internally it's using nix .. but it makes nix soooo much easier to use. With nix I've always struggled with the nix language and writing nix expressions.

If you are comfortable with nix itself, then it allows you to do a lot more than devbox does, but at the cost of extra complexity.

Depends on what level of abstraction you're looking for.

Having a deterministic environment, but that is actually running on your laptop is so much better than working inside a docker container. Inside a container the file system is very slow, and you lose all of your other tools and shell aliases.