9 ms·

I'm probably being picky, but I would also include that the CLI be a self-contained binary. I'm tired of managing Python / Ruby / Node versions.

nhumrich 8y ago
Its bad both ways. The advantage to python/ruby for example is you can simply pip/gem install, or update. With a binary, you have to download, move, and change permissions every update. For experienced linux users, the binary is fine, but for newer users, its much more "friction"
- Sean1708 8y ago
  IMO using a language's package manager to install applications is a massive anti-pattern, that should be handled by your OS package manager.
  - sudofail 8y ago
    This is what I prefer as well. Let me use my OS's package manager for managing my packages.
    - mixmastamyk 8y ago
      That would still be the case if the packages weren't 1-3 years out of date.
      - jetblackio 8y ago
        That is true. But there are ways around that. Including documentation on how to build it locally is pretty standard. And hosting prebuilt binaries with package installation for targeted platforms is also pretty common as well. With interpreted languages with language-specific package managers, you have to: 1) Install the language 1a) Possibly have to install a language version manager (rbenv, pyenv, etc) 2) Install the language's package manager 3) Install the CLI utility via the language's package manager Here's the order I think CLI maintainers should strive to making their utilities available: 1) Install via OS package manager 2) Install via prebuilt release with OS-specific package, from hosting site (GitHub, etc). 3) Install from source 4) Install via language-specific package manager 5) Install via curl | sh :)
  - nhumrich 8y ago
    The problem is, its much easier to support one language package manager, then it is to support 10 different OS package managers, not to mention, some, like debian, are near impossible to push things too.

nhumrich 8y ago

Its bad both ways. The advantage to python/ruby for example is you can simply pip/gem install, or update. With a binary, you have to download, move, and change permissions every update. For experienced linux users, the binary is fine, but for newer users, its much more "friction"

Sean1708 8y ago
IMO using a language's package manager to install applications is a massive anti-pattern, that should be handled by your OS package manager.
- sudofail 8y ago
  This is what I prefer as well. Let me use my OS's package manager for managing my packages.
  - mixmastamyk 8y ago
    That would still be the case if the packages weren't 1-3 years out of date.
    - jetblackio 8y ago
      That is true. But there are ways around that. Including documentation on how to build it locally is pretty standard. And hosting prebuilt binaries with package installation for targeted platforms is also pretty common as well. With interpreted languages with language-specific package managers, you have to: 1) Install the language 1a) Possibly have to install a language version manager (rbenv, pyenv, etc) 2) Install the language's package manager 3) Install the CLI utility via the language's package manager Here's the order I think CLI maintainers should strive to making their utilities available: 1) Install via OS package manager 2) Install via prebuilt release with OS-specific package, from hosting site (GitHub, etc). 3) Install from source 4) Install via language-specific package manager 5) Install via curl | sh :)
- nhumrich 8y ago
  The problem is, its much easier to support one language package manager, then it is to support 10 different OS package managers, not to mention, some, like debian, are near impossible to push things too.