sayanarijit

Declare settings and secret requirements and its spec in a single file for all environments, validate and deploy the settings everywhere, across programming languages.

Cottage, a git-based secrets managed tool now integrates with Claude, Copilot, Codex, Antigravity, Cursor etc to make sure your git-managed secrets are never available to AI agents.

Generate dynamic QR code from the command-line.

Age encryption allows devs to use the same ssh keys they use to access git repos, to also encrypt/decrypt secrets in the same repo, enabling an offline-first, no-vendor-lock-in, simplified development workflow.

Cottage makes it more convenient by introducing simplified recipients management with verifiable access control, standardising private key location, git hooks based automation, auto gitignore management, sync with provider and devices options, intuitive APIs etc.

Cottage is a tool for teams to manage age-encrypted secrets in git repositories.

It provides a simple workflow to encrypt/decrypt secrets, manage recipients, and keep secrets out of the repo while still allowing for easy sharing via VCS. Cottage also generates redacted previews of encrypted secrets for better visibility and supports both persistent and temporary decryption workflows, while ensuring secrets are never committed in plaintext.

I like the fend calculator that uses similar syntax.

xplr is a very flexible terminal file explorer written in Rust, which can be configured using Lua plugins.

tree-view.xplr is one example of such Lua plugins, which implements a tree-view layout for xplr, with extra functionalities.

Other similar layout plugins include:

- zentable.xplr (for a clean, distraction free view)

- dual-pane.xplr (for Midnight Commander like dual pane view)

- tri-pane.xplr (for Ranger like tri-pane view)

You can, of course, combine all of them, and toggle between different views while exploring.

Alternative to jo: https://github.com/jpmens/jo

That static executable will basically contain the whole python interpreter with a huge standard library. Maybe makes sense for a gui app, but I'd avoid installing a whole python interpreter for each of my little cli tools.

Don't forget the startup time overhead of first loading a whole interpreter into memory, then loading a python program into the interpreter.

Lua is only a configuration language without luarocks. With luarocks, we're back to the root of the argument - dependency vs standard library.

As long as there's no need to ship standalone binaries without shared libraries.

Not in rustland.

xplr author here (xplr.dev). Nice tool. Note that there's a plugin https://github.com/sayanarijit/type-to-nav.xplr that does something similar. But I just realized that tere can also be used as a more generic type-to-nav helper for xplr.

  xplr.config.modes.builtin.default.key_bindings.on_key.T = {
    help = "tere nav",
    messages = {
      { BashExec = [[echo ChangeDirectory: "'"$(tere)"'" >> "$XPLR_PIPE_MSG_IN"]] },
    },
  }

I was looking for a way to scan a QR code on my mobile using my laptop, but couldn't find a perfect solution. So I ended up making this tool.

Language: Rust

Supported platforms: Currently tested on Linux, but should also run on Unix, Linux, Mac, Windows

I just published this, so expect a few bugs here and there. If found, please report.

It's been more than one year since I made and published xplr in an attempt to satisfy my terminal productivity needs. xplr has come a long way since then, thanks to the awesome contributors who kept me encouraged. xplr is now available in almost every major developer friendly platforms via official repositories, thanks to the maintainers (see https://repology.org/project/xplr/versions). Also, thanks to Brodie Robertson for introducing xplr to a broader audience via his YouTube channel. Although, a little outdated, the basic building blocks are explained well here: https://youtu.be/MaVRtYh1IRU. The ecosystem is still immature, but it works, as I've been using it for my daily needs.

Ah I think there was miscommunication due to mental biases. Like I misunderstood your objection, you probably misunderstood the docs. I don't think the author is pretending anything. The docs says that it depends on procfs to highlight it as the main dependency or maybe the odd one.

In Rust community, it's a common knowledge that 1. If it's a high level tool, it will have multiple dependencies, and 2. The actual dependency list will be auto generated by the package managers (cargo or os) and be pinned in every release, available publicly.

Thanks for the link. It was a great read and insight into the opinions of kernel devs.

Hi, I would like to know what's wrong with a lot of dependencies? One disadvantage I know is long compile time and maybe a little larger binary size, but I don't think it's too bad.

I find this interesting: https://blog.orhun.dev/introducing-gpg-tui

I just published this plugin to showcase the new features implemented in xplr v0.15, which enables configuring xplr or creating plugins with a whole new level of interactivity in the terminal.

https://discord.gg/5aTJwnMZ has expired

Hey, not sure if it's a coincidence, but I also just made qrcode.show (terminal compatible).

Taking inspiration from Neovim, xplr v0.10 has embraced embedded luajit to enable better hackability.

You are an existing user, see the migration guide here: https://github.com/sayanarijit/xplr/wiki/Upgrade-Guide#v091-...

Listed https://github.com/sayanarijit/xplr/wiki/Alternatives

Fixed here https://github.com/sayanarijit/xplr/releases/tag/v0.3.3

Fixed here https://github.com/sayanarijit/xplr/releases/tag/v0.3.3

I'll start working on it shortly. https://github.com/sayanarijit/xplr/issues/10

I'm aware of it and will start working on it shortly. https://github.com/sayanarijit/xplr/issues/10

You should be able to configure the key bindings like mc https://github.com/sayanarijit/xplr/wiki/Key-Bindings

Also, I don't think `Cargo.lock` is a valid measure of bulk as it contains both dev and prod dependency tree. For compiled languages, the binary size probably can be a better measurement, but that's also debatable since c and c++ use shared libraries while rust uses self-contained ones.