`lix foo` should invoke `lix-foo` #342

New issue

Open

opened 2024-05-23 02:17:30 +00:00 by qyriad · 4 comments

qyriad commented

2024-05-23 02:17:30 +00:00

Owner

We know we want a Lix command. We know the Lix command suite will need significant design work. But we know one thing we definitely want: lix foo invokes lix-foo, like git commands do.

This is a very easy thing to do, and we can Just Do it

We know we want a Lix command. We know the Lix command suite will need significant design work. But we know one thing we definitely want: `lix foo` invokes `lix-foo`, like git commands do. This is a very easy thing to do, and we can Just Do it

👍 1

qyriad added this to the v2.91 milestone 2024-05-23 02:17:30 +00:00

qyriad added the

label 2024-05-23 02:17:30 +00:00

puck referenced this issue

2024-05-23 23:35:35 +00:00

print a deprecation warning for the cursed `channel:` "file" syntax #345

puck commented

2024-05-24 18:38:30 +00:00

Owner

Some question: How do we want to handle e.g. --store or other nix-global arguments? Do we pass these as specific environment variables, I guess?

Some question: How do we want to handle e.g. `--store` or other nix-global arguments? Do we pass these as specific environment variables, I guess?

qyriad commented

2024-05-24 18:46:53 +00:00

Author

Owner

That's a good question. Mostly relevant to external commands, because for our commands we can simply use the same CLI logic in every command. In a Rust world we would ideally just offer a Rust crate to magically handle global args logic

That's a good question. *Mostly* relevant to external commands, because for our commands we can simply use the same CLI logic in every command. In a Rust world we would ideally just offer a Rust crate to magically handle global args logic

pennae commented

2024-05-24 19:43:42 +00:00

Owner

since we're kind of targeting nix as the implementation language for a bunch of these as well we'd put a json object with all configs into a single environment variable with a static name shared by all commands. that way we'll get enumerability of settings (which we wouldn't get as easily with one env var per option), and a format that's much better behaved as well

jade commented

2024-05-25 02:52:08 +00:00

Owner

We should probably allow unknown options only if they're namespaced not under [lix] or so. Then we can provide config support for downstream users without regressing our own ability to keep our own stuff correct.

We should probably allow unknown options *only if they're namespaced not under [lix]* or so. Then we can provide config support for downstream users without regressing our own ability to keep our own stuff correct.