4 ms·

Import.sh A module system for Bash and other Unix shells

2 points by bfm 4y ago

bfm 4y ago
After years of using Terraform and Puppet, I seriously consider using plain bash to handle infrastructure as code on a future project, which deploys to multiple cloud and non-cloud vendors. There is some beauty to creating a standalone idempotent and well-tested bash scripts that are simple to share and version using something like import.sh Given the maturity of tools such as shellcheck, simple composable tools such as age (for encryption), machma (parallel execution), Make for the dependency graph and the assistance provided by Github Copilot to developers intimidated by bash syntax, what would be the drawbacks of going with this approach? What other simple tools like import.sh would you recommend for building IaaC pipelines?
mc4ndr3 4y ago
Curious about the cache directory tree structure. Does this play well with VCS refs, for version pinning? Does this play well with local forks, for testing and experimentation? Something like the pre go mod system could be helpful for basic shell dependency management. Also, this should really support vendoring, for users who prefer to keep a copy of the dependencies in full in their project's VCS.
- bfm 4y ago
  It looks like the IMPORT_CACHE can be used for vendoring. A quick example: #!/usr/bin/env bash export IMPORT_CACHE="vendor/import" source ./bin/import import "tootallnate/hello" import assert@2.1.3 hello assert_equal foo bar generates the following dir structure: vendor/import/ ├── data │ ├── 0a1c5188c768b3b150f1a8a104bb71a3fa160aad │ └── a4f0a20c03de97c490413f0c58f480f2ad17ba27 ├── links │ └── https │ └── import.sh │ ├── assert@2.1.3 -> ../../../data/0a1c5188c768b3b150f1a8a104bb71a3fa160aad │ └── tootallnate │ └── hello -> ../../../../data/a4f0a20c03de97c490413f0c58f480f2ad17ba27 └── locations └── https └── import.sh ├── assert@2.1.3 └── tootallnate └── hello

2 points by bfm 4y ago

bfm 4y ago

After years of using Terraform and Puppet, I seriously consider using plain bash to handle infrastructure as code on a future project, which deploys to multiple cloud and non-cloud vendors. There is some beauty to creating a standalone idempotent and well-tested bash scripts that are simple to share and version using something like import.sh Given the maturity of tools such as shellcheck, simple composable tools such as age (for encryption), machma (parallel execution), Make for the dependency graph and the assistance provided by Github Copilot to developers intimidated by bash syntax, what would be the drawbacks of going with this approach? What other simple tools like import.sh would you recommend for building IaaC pipelines?

mc4ndr3 4y ago

Curious about the cache directory tree structure. Does this play well with VCS refs, for version pinning? Does this play well with local forks, for testing and experimentation? Something like the pre go mod system could be helpful for basic shell dependency management. Also, this should really support vendoring, for users who prefer to keep a copy of the dependencies in full in their project's VCS.

bfm 4y ago
It looks like the IMPORT_CACHE can be used for vendoring. A quick example: #!/usr/bin/env bash export IMPORT_CACHE="vendor/import" source ./bin/import import "tootallnate/hello" import assert@2.1.3 hello assert_equal foo bar generates the following dir structure: vendor/import/ ├── data │ ├── 0a1c5188c768b3b150f1a8a104bb71a3fa160aad │ └── a4f0a20c03de97c490413f0c58f480f2ad17ba27 ├── links │ └── https │ └── import.sh │ ├── assert@2.1.3 -> ../../../data/0a1c5188c768b3b150f1a8a104bb71a3fa160aad │ └── tootallnate │ └── hello -> ../../../../data/a4f0a20c03de97c490413f0c58f480f2ad17ba27 └── locations └── https └── import.sh ├── assert@2.1.3 └── tootallnate └── hello