[RFC] Allow tyson config

[mikeland73]

Summary

This allows tyson config. It uses runx so the binary does not statically depend on tyson.

TODO: Need to scope tyson to only certain commands that don't modify config (otherwise we end up writing the mutations to the config).

How was it tested?

 devbox git:(landau/tyson-rc) devbox run tyson-script        
hello TySON world

[gcurtis]

My vote would be to hold off on tyson. I think we should be using the same devbox.json that our users are using, and introducing a programming language + runtime for config parsing is a huge change.

If we need this functionality internally, could we just add the typescript package and run scripts through the init hook? Or even install tyson as a regular package through runx without modifying devbox?

[mikeland73]

@gcurtis the specific use case that is interesting for us is turning package.json scripts into devbox scripts. We end up essentially copy pasting them. I'm not sure how we would solve that without something like this. I guess we could write a script that syncs them, but that's a bit manual.

This change as implemented would not replace devbox.json for us, it would simply mutate it for consumption purposes. Specifically tson would not be used to add standard packages, scripts, or anything else that is doable in json.

I'm actually not totally sold on having tyson have it's own runtime. For example we could implement something similar by just using node on the host machine or even node as installed by devbox/nix. The approach in this PR was specifically chosen to avoid including tyson as a dependency. This approach is as opt-in as I could make it and should have no risk or effect for users that don't which to use it.

[Lagoja]

I'm not sure we should merge or add TySON support unless we want to support it fully, or it unlocks some benefits that we want to leverage. Merging scripts from the package.json seems like a JS/TS specific benefit, and probably not significant enough to justify adding the feature.

Even if we're just using TySON as a mutator for the Devbox JSON, it seems like it would add complexity to managing a project's configs.

[mikeland73]

it unlocks some benefits that we want to leverage

The package.json example is a benefit. Another benefit is we can run pnpm install conditionally which will speed up running scripts. Having not to write everything in bash is a pretty big benefit.

Merging scripts from the package.json seems like a JS/TS specific benefit, and probably not significant enough to justify adding the feature.

There's nothing JS/TS specific about this example. Any other language/package manager with scripting (e.g. poetry) will have similar issues that can be solved via TySON. The concept is universal: transform scripts from framework X into devbox scripts.

Even if we're just using TySON as a mutator for the Devbox JSON, it seems like it would add complexity to managing a project's configs.

I'm not sure I understand/agree. If TySON is only evaluated if a tson file exists, this strictly limits the scope/risks of this change. Devbox continues to write only to devbox.json.

[mikeland73]

@loreto and @gcurtis thoughts on reconsidering this PR?

In the font-end repo we have package.json and devbox.json for each project and maintaining that is a pain. This change would allow us to make devbox.json mimic the package.json functionality without requiring that we copy paste every command.

I'm OK putting this behind a feature flag.

Just to reiterate,

• this PR does not pull in any tyson code or dependency. It simply installs the tyson binary only if the user opts in. So the risk is close to zero. If we add a feature flag the risk is even lower.
• This PR does not change the format of devbox.json (response to [RFC] Allow tyson config #1555 (comment))
• This PR is not specific to js/ts, it just happens that the problem I'm currently trying to solve involves a typescript stack. (response to [RFC] Allow tyson config #1555 (comment))