Allow for an official plugin to allow for customizing the devbox manifest file.

Aperta
  • Qualcosa non va?
#2,621 0 commenti 2 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
go
Ambito
tooling

Direzione di ricerca

Start by reading the Devbox plugin API and the code paths that read and write devbox.json; the issue does not name specific files or tests. Determine whether plugins can safely supply alternate manifest formats without breaking tools that expect devbox.json. Done means defining and implementing an official plugin mechanism for custom manifests, with the compatibility behavior clarified.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

feature triage
What problem are you trying to solve?

Allow arbitrary custom configs via an official plugin.

Summary

There are a lot of requests for allowing support for different configuration languages for devbox.json, such as JSONC,YAML, TOML, etc. But Devbox already includes a plugin API that allows for adding custom options to devbox.json

Related

Generalizes and might also resolve: #1590, #2169, #2602, #2480

What solution would you like?

Add support for custom manifest files, e.g. by opt-in plugins that to hook into whatever modules handle interact with devbox.json directly. Then we could achieve something like this.

(or devbox.jsonc or devbox.toml)

{
  # These are comments made with `#` because its yaml not jsonc
  "name": "",
  "version": "",
  "description": "",
  "packages": [], # or {} of packages
  "env": { "<key>": "<value>" },
  "create_files": {},
  # "<destination>": "<source>"
  "shell": {
      "init_hook": [],
      # "<bash commands>"
      "scripts": { "<key>": "<value>" },
    },
  "include": ["<path_to_plugin>"],
}

which could then be refactored to a devbox.yaml like this

name: ExampleDevboxYaml# name of your devbox shell
version: 0.0.1 # your project version
description: This is an example devbox configured with yaml
packages:
  - someNixPkgs
  - github:someFlake
  - fooPackages.bar@version^out,dev,
env:
  SOME_ENV_VAR: someValue
create_files:
  "./destination/of/file": ./source/of/file
shell:
  init_hook:
    - echo 'some bash commands'
    - echo 'or a multiline string justl like you would see with ci programs e.g. github actions'
scripts:
  someKey: someValue
include:
  - ./path/to/plugin
Alternatives you've considered
Alternative 1: Mode directive, separate .scripts directory, reconfiguring your IDE

See this, my comment here.
Originally posted by @CourteousCoder in #2602

This is my current solution.

Alternative 2: Custom plugin with additional config file

Create a community-maintained custom plugin that provides an additional config file.

This might be A more flexible long-term solution. In theory, it provides an indirect way to use a different config language.

Then, devbox.json would theoretically still be the only configuration file devbox looks for.

I think we might already have a way to implement this with the existing plugin API. I have not verified this.

Based on the current plugin API (Wayback Machine archive), I don't see why a plugin couldn't adhere to the devbox schema and then utilize its own config file (e.g. a plugin:yaml could manage to utilize a devbox.yaml and implement the same schema as devbox.json, but in yaml.

There might be a corner case where another external plugin, script, or utility reads to or writes from devbox.json directly. That might break compatibility with a yaml format.

But basically your devbox.json would be merely:

{
 "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.14.2/.schema/devbox.schema.json",

  "include": [
      // or perhaps "plugin:devbox-yaml", or even "plugin:yaml" for brevity
      // or for whatever kind of config language support you want.
      // "plugin:toml",
      // "plugin:jsonc",
      // "plugin:dhall",
      // ...
      "plugin:manifest-yaml",
  ]
}

And then you could put the yaml configuration into devbox.d/manifest-yaml/devbox.yaml, or perhaps configure the plugin to look for devbox.yaml in the root of the project.

Alternative 3: Hardlink (JSONC only)

A horrible idea in my opinion. But it is an option, I suppose.

Maintain an automated hardlink between devbox.jsonc and devbox.json and add devbox.json to .gitignore

Alternative 4: Preprocessing

Write some sort of adapter, wrapper, pre-commit hook, plugin, or service to synchronize devbox.json with some devbox.yaml, devbox.toml, devbox.jsonc

Cumbersome and against the design goal of devbox to simplify nix configs for development environments.

This is one of the main use cases of DHALL. A really cool config language in opinion. However, I don't think it really resolves the related issues I've referenced here, nor aligns with devbox's design goals of having a sugary and familiar dev UX around nix.

Lingua principale
Go
Stelle
12.4k
Fork
358
Merge medio
17h 12m
PR unite (30g)
31

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di jetify-com/devbox

Tutte le issue di jetify-com/devbox

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.