lix-project/lix

Fork 54

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

New issue

Closed

opened 2024-05-23 02:17:30 +00:00 by qyriad · 6 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.

jade modified the milestone from v2.91 to post-release

2024-08-13 01:19:36 +00:00

rbt changed title from ~~lix command MVP: do the git thing~~ to lix foo should invoke lix-foo

2024-08-26 22:57:44 +00:00

jade referenced this issue

2024-09-08 10:07:44 +00:00

Consider adopting default-flake from nix-dram #502

ian-h-chamberlain referenced this issue

2024-09-08 15:34:59 +00:00

Consider adopting default-flake from nix-dram #502

rbt referenced this issue

2024-09-10 00:15:32 +00:00

Lix should include a lix executable #508

lix-bot commented

2024-12-27 13:46:34 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

comment in cl/2119 ("feat: add support for external lix- prefixed commands in the CLI")

This issue was mentioned on Gerrit on the following CLs: * comment in [cl/2119](https://gerrit.lix.systems/c/lix/+/2119) ("feat: add support for external `lix-` prefixed commands in the CLI")

pennae commented

2025-03-04 15:11:09 +00:00

Owner

we have this now :D