best practice(s) for re-using devbox scripts?

[justinTM]

What problem are you trying to solve?

I have a lot of projects with very similar devbox.json files. i'm wondering what ideas people have for keeping them synchronized?

my projects are a lot of AWS Lambdas based on python, deployed as docker images using terraform

• init hooks
  • gather or generate variables like project name, build targets, docker image tags
  • source parameters/*.env files
  • activate python virtual env if not already activated
  • set up aws credentials
• scripts
  • build my docker images
  • run images as lambdas i can invoke via curl
  • run unit tests

i guess i'm wondering if Don't Repeat Yourself DRY principles are more important than have reproducible projects without a lot of dependencies (git submodules, gitlab pipeline imports, poetry python packages via git, etc.).

What solution would you like?

I would love a way to import and re-use devbox config between projects. not sure what it would look like, but maybe a git URL and branch to define common scripts and init hooks which can be overridden

Alternatives you've considered

• git submodules containing bash scripts
• moving scripts to GitLab CI and using gitlab-ci-local
• making a generic template project for common setups (python lambda via docker, gitlab pipelines for data cleaning, terraform infrastructure, etc.)

[Lagoja]

Hey @justinTM

I think a good way to reuse scripts, packages, and other configuration is with Devbox Plugins.

As of Devbox 0.10, you can now define scripts and environment variables in a plugin that can be included in multiple projects. You can even host plugins remotely in Github, if you don't want to copy the plugin to all of your different projects.

Would this address the use cases you're describing?

[svallory]

@Lagoja I've been trying that approach with varying success. Here are some things I think can be improved:

• create_files could accept a glob when the destination is a folder
• I really miss an env or template variable with the plugin's original path
• circular reference detection is buggy and I've had to resort do documenting required order of plugins in the devbox.json
• a setup hook that runs only once would also be very helpful (I'm currently resorting to creating/checking the presence of a .setup-complete file)