[Proposal]: Custom settings

[denyncrawford]

Proposal

It would be beneficial to provide a means for users to specify custom end-user configurations. There are scenarios where you might need to adjust settings such as:

• Version to install
• Custom package names
• Custom installation names

When attempting to install a package, it is suffixed by the operating system, and it would be advantageous to have the flexibility to modify this behavior. For instance, if I want to test various installations and assign them distinct names, or if an end-user has a global executable with the same name and wants to rename it.

Is there a method to pass arguments, perhaps using query parameters or URL parameters? I'm aware that you already offer this capability with the verbose option.

[MarvinJWendt]

Hi @denyncrawford, I am planning to include a version selector something like this instl.sh/user/[email protected]/linux. Would that fit your need?

The custom installation and package names are difficult tho.

When attempting to install a package, it is suffixed by the operating system, and it would be advantageous to have the flexibility to modify this behavior.

Instl doesn't change the binary names. They are used as-is from the assets. So if your installation has an operating system suffix, it means that your binaries have them too. Generally speaking, if someone downloads your assets manually, he would also have to rename them manually. I recommend publishing the binaries without an operating system suffix, e.g.: linux.tar/your_cli, windows.zip/your_cli.exe, ...

I thought about config files, inside the repositories, where maintainers can specify the name of the binary.

The problem with renaming the binaries via instl, is that we can never be sure which binary is the right one. For example, let's imagine the following scenario:

A big GitHub project has multiple files in the released assets (probably dependencies). We can not figure out which binary file is the actual CLI and which files are assets or dependencies. So instl can't just choose a random one that should be renamed.

I am open for suggestions, but currently I don't see a way to accurately identify the main binary file. There are also projects, that release multiple binaries at once, like server, db-admin, db-migrate, etc. All of those files would have to stick to their original names. When a user would change the name via a parameter, instl could only rename one binary.

PS:

or if an end-user has a global executable with the same name and wants to rename it.

I think this might be a problem with every package manager. Duplicates are hard to detect (we would need to scan every directory in the users PATH env variable). When you use npm, Go, homebrew, etc. there is always a possibility that files with the same name already exist. I am not sure how we could tackle this, without needing to scan, maybe thousands, of files each time.

[denyncrawford]

Hi @MarvinJWendt I think it's a great idea to include configuration files in repositories. When the configuration is within the repository, it can be managed differently. This allows for the mapping of binaries for installation and executing tasks with additional information, such as names or custom post-install messages.

With this setup, it becomes effortless to install specific binaries using URLs like instl.sh/user/[email protected]/my-bin-name/linux.

The configuration format could be structured as follows:

For a single entry:

// .instl
{
  "name": "my-custom-name",
  "macos": "macos.zip",
  "windows": "windows.zip",
  "linux": "linux.zip",
  "post-install": {
    "message": "Custom post-install message here"
  }
}

For multiple entries:

// .instl
[
  {
    "name": "app-1",
    "macos": "app-1-macos.zip",
    "windows": "app-1-windows.zip",
    "linux": "app-1-linux.zip",
    "post-install": {
      "message": "Custom post-install message for app-1"
    }
  },
  {
    "name": "app-2",
    "macos": "app-2-macos.zip",
    "windows": "app-2-windows.zip",
    "linux": "app-2-linux.zip",
  },
  {
    "name": "app-3",
    "macos": "app-3-macos.zip",
    "windows": "app-3-windows.zip",
    "linux": "app-3-linux.zip",
  }
]

If as config file doesn't exist then it acts like it does now.

This approach also provides information about what binaries or files are instalable within all available files into the release.