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.

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.