Skip to content

Files

Latest commit

heltonhelton
feat: add command hbox config
May 19, 2024
86c10e0 · May 19, 2024

History

History
52 lines (50 loc) · 2.56 KB

ROADMAP.md

File metadata and controls

52 lines (50 loc) · 2.56 KB

Roadmap

List of ideas I want to implement in the future.

  • Miscellaneous:
    • Support private registries and mirrors
    • maybe via registry mapping in config.json?
    • Add a .gif showcasing hbox
    • Update GitHub workflows to
      • upload binaries to release
      • add linters and code format
      • add static analysis
      • add image scanning
    • Create an index/registry repository
    • Use shards to get better performance in git repositories
    • Double check if registered packages are available locally before using them
    • Manage volumes to avoid lose data
      • probably better to manage them by package + version
    • Make it easier to build custom images based on templates
      • pass relevant build args, like IMAGE_NAME and IMAGE_VERSION
    • Try to update config files from .json to .yaml or .toml
    • Mask relevant information added to logs
    • Allow override configs and versions in a local folder, via .hbox file (or other file extension)
      • Traverse parent directories until a .hbox config file is found
        • does it need to define depth level?
    • Add version to config files to specify their formats to allow check for future compatibility
    • [Experimental] Allow forced flags in docker run, based on pattern matching
  • New commands
    • Add auto update hbox upgrade
    • Add hbox update to update index
    • Add hbox register to register a package, even with custom image
    • Add hbox verify to check if there's something wrong with packages or with container engine:
      • Verify if docker or podman are installed and available
        • Verify if there are container images for the current version of each package
    • Add command hbox reshim to regenerate shims
    • Experimental: Identify paths in hbox run to map them via container volumes automatically
  • Updated commands:
    • Add option to keep containers instead of using --rm
      • maybe adding custom tags to them to identify them easily?
      • define lifecycle rules:
        • should we reuse them or always create a new one?
        • should volumes be reused between them?
    • Add option to remove images when removing packages via hbox remove/uninstall
    • Add support to colors in hbox run output when possible (*nix only?)
    • On hbox add/install add warn when a shim will conflict with an existing command
  • Technical debt:
    • Add unit and integration tests
      • it should run on Linux and Windows