lix-project/lix

Fork 27

Consider adopting `default-flake` from `nix-dram` #502

New issue

Closed

opened 2024-09-07 23:48:31 +00:00 by ian-h-chamberlain · 5 comments

ian-h-chamberlain commented

2024-09-07 23:48:31 +00:00

I think most of the reasoning for this is described well in the upstream issue which was ultimately rejected.

TLDR: It can be annoying to type nixpkgs# every time you run a CLI command using installables, so the idea is to make it possible to specify a "default flake" which is used by default for CLI commands that take installables, like nix shell, nix search, nix run.

I think this is an area where Lix has an opportunity to make its UX more ergonomic than upstream for a common use case!

Describe the solution you'd like

Pull in one or more patches from nix-dram (nix-flake-default.patch), or at least use it as a starting point to support a default-flake option. nix-search-pretty may also be useful as a way to improve the UX of nix search, although IMO is less important / should be tracked separately anyway.

Describe alternatives you've considered

Leave the CLI interfaces as-is. This would be a fairly large change, and could break muscle memory for existing users, so this might be an argument in favor of leaving it unchanged.
Support both types of usage, i.e. default-flake = null -> current behavior, default-flake = "flake:..." -> works like nix-dram. This would add some maintenance burden, but also would avoid erroring out when default-flake is unset, making migration easier and the use of this feature optional.

Additional context

None I can think of.

## Is your feature request related to a problem? Please describe. I think most of the reasoning for this is described well in the [upstream issue](https://github.com/NixOS/nix/issues/4438) which was ultimately rejected. TLDR: It can be annoying to type `nixpkgs#` every time you run a CLI command using installables, so the idea is to make it possible to specify a "default flake" which is used by default for CLI commands that take installables, like `nix shell`, `nix search`, `nix run`. I think this is an area where Lix has an opportunity to make its UX more ergonomic than upstream for a common use case! ## Describe the solution you'd like Pull in one or more patches from [nix-dram](https://github.com/dramforever/nix-dram) (`nix-flake-default.patch`), or at least use it as a starting point to support a `default-flake` option. `nix-search-pretty` may also be useful as a way to improve the UX of `nix search`, although IMO is less important / should be tracked separately anyway. ## Describe alternatives you've considered - Leave the CLI interfaces as-is. This would be a fairly large change, and could break muscle memory for existing users, so this might be an argument in favor of leaving it unchanged. - Support both types of usage, i.e. `default-flake = null` -> current behavior, `default-flake = "flake:..."` -> works like `nix-dram`. This would add some maintenance burden, but also would avoid erroring out when `default-flake` is unset, making migration easier and the use of this feature optional. ## Additional context None I can think of.

pennae commented

2024-09-08 00:01:46 +00:00

Owner

it's not just muscle memory here, this actually breaks things: running flake-based applications from registries directly when invoked as eg nix run blender will no longer do what it previously did. default-flake as a config option is short-sighted, we'd be a lot better off adding custom subcommands to lix (such that one could say, for example, alias.run = !lix flake run nixpkgs#$1).

not saying that the current cli is good, but if we're going to change anything we may as well think it through properly instead of just piling on ever more inconsistent hacks on an already broken system?

it's not just muscle memory here, this actually breaks things: running flake-based applications from registries directly when invoked as eg `nix run blender` will no longer do what it previously did. `default-flake` as a config option is short-sighted, we'd be a lot better off adding custom subcommands to lix (such that one could say, for example, `alias.run = !lix flake run nixpkgs#$1`). not saying that the current cli is good, but if we're going to change anything we may as well think it through *properly* instead of just piling on ever more inconsistent hacks on an already broken system?

ian-h-chamberlain commented

2024-09-08 02:30:03 +00:00

Author

eg nix run blender will no longer do what it previously did. default-flake as a config option is short-sighted, we'd be a lot better off adding custom subcommands to lix (such that one could say, for example, alias.run = !lix flake run nixpkgs#$1).

That's true, I wasn't thinking about flakes of that sort, but I guess the nix-dram syntax for this case would be to nix run flake:blender or nix run blender#.

Still, I think an alias or custom subcommand like you suggest would also work to improve the UX and be more flexible all-around. I suppose to support the specific example you gave (i.e. override builtin subcommands), it would need to handle recursion on aliases like that, although as a workaround you could probably do something like alias.r = run nixpkgs#$1 instead. Maybe a script (a la cargo-subcommand) would be simpler to deal with?

Are there any existing proposals for external subcommands / aliases like that? I guess plugin-files might be an option you can use today, although it's fairly awkward to use... now I'm wondering if it's feasible to write plugin that just registers a bunch of subcommands for scripts in a directory or something... This probably also wouldn't be able to override builtin subcommands?

> eg `nix run blender` will no longer do what it previously did. `default-flake` as a config option is short-sighted, we'd be a lot better off adding custom subcommands to lix (such that one could say, for example, `alias.run = !lix flake run nixpkgs#$1`). That's true, I wasn't thinking about flakes of that sort, but I guess the `nix-dram` syntax for this case would be to `nix run flake:blender` or `nix run blender#`. Still, I think an alias or custom subcommand like you suggest would also work to improve the UX and be more flexible all-around. I suppose to support the specific example you gave (i.e. override builtin subcommands), it would need to handle recursion on aliases like that, although as a workaround you could probably do something like `alias.r = run nixpkgs#$1` instead. Maybe a script (a la `cargo-subcommand`) would be simpler to deal with? Are there any existing proposals for external subcommands / aliases like that? I guess `plugin-files` might be an option you can use today, although it's fairly awkward to use... now I'm wondering if it's feasible to write plugin that just registers a bunch of subcommands for scripts in a directory or something... This probably also wouldn't be able to override builtin subcommands?

jade commented

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

Owner

#342

https://git.lix.systems/lix-project/lix/issues/342

👍 1

jade commented

2024-09-08 10:17:16 +00:00

Owner

We have a lot of tech debt. The "2.0" flakes cli is unlikely to change incompatibly so this proposal is probably not going to happen to the 2.0 cli. In any replacement CLI (though one has not yet been designed) it seems unlikely that we would want to make nixpkgs special, as this idea would necessitate; or having a default flake. In the legacy 1.0 CLI we already have nix-defexpr to implement essentially this behaviour and it's extremely cursed, underdocumented and probably altogether a bad idea.

You can solve your current problem using the shell: nix shell nixpkgs#{hello,python3,bc}, or by writing a wrapper script.

As for doing anything with config, tbh the config system needs rewriting to be able to do toml (or whatever else) configuration and it's just not anyone's top priority and would step on the toes of the ongoing work to convert configuration stuff to generated code (fixing the docs pipeline that currently doesn't work on cross compiled builds because you otherwise have to run the cross compiled lix to extract the docs that are written in c++ files). Having an alias section with decent ergonomics would require improving the configuration system to not be one single level, and it's just not the hottest fire right now. We have a lot of tech debt. The "2.0" flakes cli is unlikely to change incompatibly so this proposal is probably not going to happen to the 2.0 cli. In any replacement CLI (though one has not yet been designed) it seems unlikely that we would want to make nixpkgs special, as this idea would necessitate; or having a default flake. In the legacy 1.0 CLI we already have nix-defexpr to implement essentially this behaviour and it's extremely cursed, underdocumented and probably altogether a bad idea. You can solve your current problem using the shell: `nix shell nixpkgs#{hello,python3,bc}`, or by writing a wrapper script.

ian-h-chamberlain commented

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

Author

I'll explore other avenues for my own convenience for now, and it sounds like the proposal in #342 would resolve this in a new CLI at least, so I guess I'll close this as I don't think there's anything actionable here. Thanks for the discussion!

Gotcha, all that makes sense and I can understand there is a lot of other stuff that is higher priority. Designing a feature where users can customize their CLI to make shortcuts like this seems like a better approach long term but does sound like it would take a lot of work technically to make work. I'll explore other avenues for my own convenience for now, and it sounds like the proposal in #342 would resolve this in a new CLI at least, so I guess I'll close this as I don't think there's anything actionable here. Thanks for the discussion!

ian-h-chamberlain closed this issue

2024-09-08 15:35:00 +00:00

No milestone

No project

No assignees

3 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#502

No description provided.

Consider adopting default-flake from nix-dram #502

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Consider adopting `default-flake` from `nix-dram` #502