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

Abierto
  • ¿Algo no está bien?
#2,621 0 comentarios 2 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
go
Área
tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
12.4k
Forks
358
Merge medio
17 h 12 min
PR fusionados (30 d)
31

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de jetify-com/devbox

Todos los issues de jetify-com/devbox

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.