5 ms·

Look, I don't have a need for this application, but from the presentation of supported platforms: > Linux > Homebrew > Arch Linux > pacman -U jless First,

Look, I don't have a need for this application, but from the presentation of supported platforms: > Linux > Homebrew > Arch Linux > pacman -U jless First, if you have to revert to homebrew as a package manager on gnu/linux you might as well tell the user to just use cargo directly, that way users only have to install the rust toolchain as opposed to the rust toolchain plus an alien package manger. The typical way would be to make cargo compile the thing, place in in ~/.local somewhere and add that path to PATH. Second, "pacman -U ARG" installs from a file or from a URI. jless is neither. You have to properly package it before pacman will install from a file, which means you have to write a PKGBUILD file with some metadata and build instructions (about 20 lines) and call makepkg, which will then produce the package (a .tar.xz file if I'm not mistaken). I suggest you first test the instructions you put on your website.

CodeIsTheEnd 5y ago
Sorry! Someone already filed an issue about this [1], but I haven't had time to investigate exactly what is appropriate to put there. I don't use Linux, nor have I ever released and distributed open-source software before, so I'm just kinda guessing here -- other people have added the project to various package managers, not me. Installing via Linux Homebrew is simply listed as an option because it's available as a Homebrew formula. And the option to install via cargo is also noted. [1]: https://github.com/PaulJuliusMartinez/jless/issues/46 https://github.com/PaulJuliusMartinez/jless/issues/46
- boudin 5y ago
  As mentioned in this issue you should not give an install command since it's in the AUR. You can just mention it's available in the AUR and provide a link to the package instead: https://aur.archlinux.org/packages/jless https://aur.archlinux.org/packages/jless
akvadrako 5y ago
I find linuxbrew to be a welcome option since it's one of the most generic methods available. It works on most distros and for most languages, instead of being tied to, say, rust or arch.
- f1refly 5y ago
  But, as said, for it to work you have to set up yet another package manager which will works against the systems package manager, leading to out of date packages and probably broken dependencies. Rust already has a working system that will put binaries to a standardized place that will properly integrate.
  - akvadrako 5y ago
    I know almost nothing about cargo since I don't do rust, but if it works as you say, integrating with the system's packages, you are more likely to end up with broken dependencies. Brew keeps it's packages separate, so breaking is less likely.
    - f1refly 5y ago
      No, it won't. When rust "installs" an application, it will compile it as described in the cargo.toml, then put the resulting binary file in "~/.cargo/bin" (just looked it up to be sure). The user can then either execut from that directory directly or prefix PATH with it in his ~/.profile or similar files, making it available like any other program. A separate package manager is not remotely needed for this and thus poses an unnecessary dependency and burden on users who didn't have homebrew installed. It integrates with the systems package manager in that it takes higher priority (well, or lower, depending on wether PATH was prepended or appended) during application lookup and does nothing else. Without looking at it I'd guess that homebrew does the same. > I know almost nothing about cargo since I don't do rust And you don't have to. Git clone, cargo install, add line to .profile (if not already there), done.
      - akvadrako 5y ago
        I don't see how any of that is better than brew. There is lots missing from your "no knowledge is needed" stance, like (1) how to install cargo (2) how to uninstall packages (3) how to upgrade them (4) how to install binaries without compiling. For people who already have brew installed (since it works for much more than cargo) these things are already known.
bluejekyll 5y ago
> you might as well tell the user to just use cargo directly For Rust projects, there really is no need for more than this. It might take a bit longer, but it’s simple and easy.
- heleninboodler 5y ago
  I really hope this trend doesn't continue, honestly. I shouldn't need the toolchain for a language that something was written in just to use that thing. It's very common with Go projects, too, but it's kind of a reversion back to the "./configure; make ; make install" days.
  - HelloNurse 5y ago
    Most modern toolchains are robust, easy to use, and shared between many non-packages. Go, Rust and Node.js cover a large portion of recent projects, and many others cheat with Docker or the like.
  - bluejekyll 5y ago
    As far as I can tell, most of the package managers are just calling cargo under the covers anyway.
    - mgalgs 5y ago
      Only if they're building from scratch. Binary packages would have no need for cargo.

CodeIsTheEnd 5y ago

Sorry! Someone already filed an issue about this [1], but I haven't had time to investigate exactly what is appropriate to put there. I don't use Linux, nor have I ever released and distributed open-source software before, so I'm just kinda guessing here -- other people have added the project to various package managers, not me. Installing via Linux Homebrew is simply listed as an option because it's available as a Homebrew formula. And the option to install via cargo is also noted. [1]: https://github.com/PaulJuliusMartinez/jless/issues/46 https://github.com/PaulJuliusMartinez/jless/issues/46

boudin 5y ago
As mentioned in this issue you should not give an install command since it's in the AUR. You can just mention it's available in the AUR and provide a link to the package instead: https://aur.archlinux.org/packages/jless https://aur.archlinux.org/packages/jless

akvadrako 5y ago

I find linuxbrew to be a welcome option since it's one of the most generic methods available. It works on most distros and for most languages, instead of being tied to, say, rust or arch.

f1refly 5y ago
But, as said, for it to work you have to set up yet another package manager which will works against the systems package manager, leading to out of date packages and probably broken dependencies. Rust already has a working system that will put binaries to a standardized place that will properly integrate.
- akvadrako 5y ago
  I know almost nothing about cargo since I don't do rust, but if it works as you say, integrating with the system's packages, you are more likely to end up with broken dependencies. Brew keeps it's packages separate, so breaking is less likely.
  - f1refly 5y ago
    No, it won't. When rust "installs" an application, it will compile it as described in the cargo.toml, then put the resulting binary file in "~/.cargo/bin" (just looked it up to be sure). The user can then either execut from that directory directly or prefix PATH with it in his ~/.profile or similar files, making it available like any other program. A separate package manager is not remotely needed for this and thus poses an unnecessary dependency and burden on users who didn't have homebrew installed. It integrates with the systems package manager in that it takes higher priority (well, or lower, depending on wether PATH was prepended or appended) during application lookup and does nothing else. Without looking at it I'd guess that homebrew does the same. > I know almost nothing about cargo since I don't do rust And you don't have to. Git clone, cargo install, add line to .profile (if not already there), done.
    - akvadrako 5y ago
      I don't see how any of that is better than brew. There is lots missing from your "no knowledge is needed" stance, like (1) how to install cargo (2) how to uninstall packages (3) how to upgrade them (4) how to install binaries without compiling. For people who already have brew installed (since it works for much more than cargo) these things are already known.

bluejekyll 5y ago

> you might as well tell the user to just use cargo directly For Rust projects, there really is no need for more than this. It might take a bit longer, but it’s simple and easy.

heleninboodler 5y ago
I really hope this trend doesn't continue, honestly. I shouldn't need the toolchain for a language that something was written in just to use that thing. It's very common with Go projects, too, but it's kind of a reversion back to the "./configure; make ; make install" days.
- HelloNurse 5y ago
  Most modern toolchains are robust, easy to use, and shared between many non-packages. Go, Rust and Node.js cover a large portion of recent projects, and many others cheat with Docker or the like.
- bluejekyll 5y ago
  As far as I can tell, most of the package managers are just calling cargo under the covers anyway.
  - mgalgs 5y ago
    Only if they're building from scratch. Binary packages would have no need for cargo.