Is your feature request related to a problem? Please describe.
As someone interested in acquiring one of these fancy, new Apple M1 machines, I would like to be able to provision my machine with native ARM software and get this fancy beast of a machine provisioned like my existing amd64 machines.

Describe the solution you'd like
Run mstrap on an M1 machine without using Rosetta 2

Describe alternatives you've considered
Running with Rosetta 2

Describe how this fits in with the project's aims (as described here)
N/A

Checklist

• I have read the project aims on the documentation site
• To the best of my knowledge, I am not asking about an existing feature request

Barriers to start:

• strap.sh support for Big Sur and M1 silicon
• Crystal support for M1 silicon (crystal-lang/crystal#10066)
  • Works, but compiler has to be cross-compiled on an M1 machine with the x86_64 version linked to LLVM 11 in order to get a working arm64 build of the compiler. It's a pain in the ass, and should be more easily cross-compilable and installable via Brew once builds ship based on LLVM 11.
• Homebrew support for M1 silicon
  • mostly works, but need a story around supporting both ARM and Intel installs
• Docker support for M1 silicon

Describe what you're trying to do:
When defining a top-level runtime configuration block, possibly with a default_version or a set of packages defined, what should mstrap do if no projects are found to use the runtime? Should default_version be installed? Should the defined packages be installed? If no default_version is set, should the latest version be installed?

Checklist:

• I checked the documentation site and the content is either not documented or the explanation was unclear (please expand, if so)

Describe the bug

There's an issue creating an OpenSSL context on Fedora 37 and 38 using their respective Docker images, specifically this error:

Unhandled exception: SSL_CTX_new: error:030000A9:digital envelope routines::unknown option (OpenSSL::Error)

This seems to be a pretty common type of error to see from the OpenSSL 1.1 -> 3.0 transition, so I suspect it's related to this somehow.

This error was seen for both GNU and musl libc. GNU was tested locally and musl libc & static linking were tested via CI and locally.

To Reproduce

Run make smoke-test TARGET_OS=linux TEST_NAME=fedora-37-test. It will fail with an error like the above (but with a stacktrace available)

Expected behavior

It should succeed!

Logs or screenshots
If applicable, add logs or screenshots to help explain your problem. Please remove any sensitive information!

Please complete the following information:

• OS: Fedora
• Architecture: amd64, aarch64
• Version: 37, 38

Additional context

Is this worth solving? Probably not. Time will tell, but Fedora 39 probably fixes it and will probably happen before I get around to investigating this.

Checklist

• I have tried running with --debug and troubleshooting based on that output
• I have provided relevant steps to reproduce
• I have provided a log file and/or screenshots and have verified there is nothing sensitive
• I am not asking for general troubleshooting/assistance with using the software

Most of mstrap is built somewhat with platform-independence in mind (at least *nix) but there are some hurdles in dependency setup that need to be implemented specially for each platform.

Linux Prerequisites

• strap.sh for Linux
  • Setup Git config defaults
  • Install Homebrew
  • Pull dotfiles and run dotfiles scripts
  • Pull and execute user Brewfile
  • Custom homebrew tap & brew command env var support
• Remove Docker for Mac checks on non-Darwin targets

mise f.k.a. rtx carries a number of benefits or additional features over asdf, namely some performance improvements, built-in language runtime version management support (e.g. no plugins needed for Ruby), fast native binaries, and direnv & make-like capabilities

Describe the solution you'd like

Creating configurable runtime manager abstraction to allow mise to be used as the runtime manager for language runtimes in projects setup by mstrap. This structure could in the future allow for potentially adopting other (or multiple) runtime managers (e.g. using rustup for Rust, mise for others, etc.)

Describe alternatives you've considered

Continuing w/ the asdf integration as-is

Describe how this fits in with the project's aims (as described here)

Mise is an opinionated tool whose opinions align well w/ mstrap aims so far. The direnv-like environment variable management and task runner capabilities could be useful to build off of in the future (e.g. calling specific hooks defined as mise tasks or setting up project environment variables)

Additional context

Ultimately, I'd like to move to mise becoming the default, but for now it will be opt-in via a setting in config.hcl for experimentation. Continuing w/ asdf as a default is an option, if for some reason mise appears not to be a suitable default.

Checklist

• I have read the project aims on the documentation site
• To the best of my knowledge, I am not asking about an existing feature request

TODO

• RuntimeManager abstraction && mise RuntimeManager implementation (#50)
• #52
• Document config schema changes

Describe the bug
When copying an SSH git URL from GitHub to use as a profile's URL, if you don't replace the : with a / it will get interpreted as a port, and throw an error. We should catch this exception/URI parsing error and provide better messaging

To Reproduce

Use a bad URI for a profile

Expected behavior

It doesn't crash the program and gives you a nice message

Logs or screenshots

$ mstrap update-profiles
Unhandled exception: Invalid URI: bad port at character 21 (URI::Error)
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???

Please complete the following information:

• OS: any
• Architecture: any
• Version any

Additional context
Add any other context about the problem here.

Checklist

• I have tried running with --debug and troubleshooting based on that output
• I have provided relevant steps to reproduce
• I have provided a log file and/or screenshots and have verified there is nothing sensitive
• I am not asking for general troubleshooting/assistance with using the software

This will be important for automating getting Ruby installed & Homebrew setup on linux-arm64/aarch64. On of the challenges with getting setup on non-darwin arm64/aarch64 target, is that Homebrew does not ship a portable Ruby installation, requiring those platforms to install a compatible Ruby version first.

By installing mise upfront, and using it to install a compatible Ruby version as-needed, we can make the experience much easier for Linux on arm64/aarch64