Hacker News Reader

Hacker News

Comment by f1refly | Hacker News Reader

Full thread

f1refly

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.

View on HN

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

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

> 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.

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.

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.

As far as I can tell, most of the package managers are just calling cargo under the covers anyway.

Only if they're building from scratch. Binary packages would have no need for cargo.

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.

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.

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.

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.

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.

I like Linuxbrew because I can install things without needing to mess with the system packages. I'm using it on my TrusNAS SCALE server to install things like fish and neovim. The stance of iXsystems has always been that TrueNAS is an appliance and you shouldn't touch the system packages, so I try not to apt install anything.

Reply on news.ycombinator.com