cargo-ebuild VS xplr

In Gentoo, Rust crates are just normal files to be downloaded in order to build a given package. The package pins (and checks the hashes of) the crate deps, and builds using cargo --offline. There is no serde/clap/etc packages, just ripgrep/librsvg/etc packages. There is no need to patch all packages to use the same serde crate version. Packaging a Rust program in gentoo is pretty much automatic.

Then, I went through like 3 different pages on gentoo and learned how to make my own rebuild using this... But after setting up my custom repo and making sure it had the right permissions, manifest, etc. the ebuild failed on account of not being able to find the Config.yoml file it needed, which exists in the directory I built the ebuild from. I think I am just SOL on this, and will have to probably find a different approach

FWIW it's worth for portage (Gentoo) there is g-sorcery[0], which can create ebuilds for Emacs (m/elpa) and python packages automatically. Similarly there is also cargo-ebuild[1] which can create ebuilds for rust programs/libraries, including a list of all dependencies with hashes.

I've successfully used cargo-ebuild in the past to create ebuilds automatically, it's a breeze. I'd be surprised if similar tools didn't exist for deb/rpm based distros.

[0]:https://github.com/jauhien/g-sorcery

[1]: https://github.com/cardoe/cargo-ebuild

I'm working on a custom repository where I intend to write ebuild files for packages that's not supported by Gentoo's repository. Right now, I'm trying to write an ebuild file for xplr, which is a Rust project that uses the Cargo build system. Initially, I used the cargo-ebuild tool, which generated the file xplr-0.14.3.ebuild.

Maybe you already know, but specifically for making Rust ebuilds and filling the CRATES variable there's a tool cargo-ebuild to automatically extract that from Cargo.toml.

I have zero issues with Gentoo's Rust and Rust-using packages. I use rustup's Rust and cargo install for development, and maintain a gentoo package using cargo ebuild.

I use xplr and like it very much.

xplr

PIC stands for Preview Image in CLI, I think this should be explicit enough. I first made it because I needed a way to display images in the terminal (for an xplr plugin), but the more I worked on it, the better it got, as of now I have implemented 4 different ways to preview images (I couldn't find other ones), some can even display GIFs!

Certain file managers like xplr allow for more advanced terminal UX. Check out the video on https://xplr.dev/ and you can see something like a live/interactive ls that allows toggling arguments (instead of running multiple commands and pushing previous stdout further into the past).

xplr version 0.20.0 was released last week. If you haven't already, go ahead and install the latest version. This post will try to break down the changelog in the release in an easy-to-digest manner, looking through the perspective of different user groups.

Tool: https://xplr.dev

The Vim/Neovim ecosystem has gotten unbelievably better over the last 5-10 years. "Living in the terminal" for core development work is IMO better than pretty much anything else out there; my Neovim setup has a modern plugin manager; an IDE-like experience with fast autocompletion as I type, goto definition, and automated refactor support; and a side-drawer file browser navigable with Vim motions. It feels like an IDE, except that it launches in ~100ms and has ultra-low typing latency. Using it with tmux panes means I can have various drawers and panes with a series of full, incredibly fast terminals wherever I want, with long-running tasks like automated test watching/running while I edit code placed wherever I want around the editor panel. Not to mention the Cambrian explosion of "modern" terminal tooling getting built, like xplr [1], hyperfine [2], httpie [3], etc.

That being said, I think "living in the terminal" for general purpose computing, like browsing the web or talking to your coworkers, has been in a kind of frozen standstill while the rest of the world has moved on. I think it isn't worth trying to push non-dev work into the terminal currently.

1: https://github.com/sayanarijit/xplr

2: https://github.com/sharkdp/hyperfine

3: https://github.com/httpie/httpie

a terminal file manager built in rust I just heard about

I tried using nnn but didn't find it easy to adopt, now I'm looking at https://github.com/sayanarijit/xplr