lix-project/lix

Fork 31

nix-shell -p always includes a gcc #377

New issue

Open

opened 2024-06-06 23:33:40 +00:00 by stuebinm · 6 comments

stuebinm commented

2024-06-06 23:33:40 +00:00

Member

Describe the bug

Any invocation of nix-shell -p <some-packages> will always include gcc in the shell it builds. Usually this isn't much of an issue, but it can become very annoying on disk-space constrained machines, on machines with a slow connection to the cache, or if one wants to use another cc which will get shadowed by any nix-shell, with no hint on that in the documentation (or at least none that i could find).

In particular, even nix-shell -p clang will still also include a gcc.

An issue was filed on this for nix a while ago, but got no response: https://github.com/NixOS/nix/issues/5117

Steps To Reproduce

❯ nix-shell -p hello --pure --command "cc --version"
gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Expected behavior

The above should result in cc: command not found.

`nix --version` output

nix (Lix, like Nix) 2.90.0-lix

Additional context

This is caused by using pkgs.runCommandCC in the templated nix expression used for -p in https://git.lix.systems/lix-project/lix/src/branch/main/src/nix-build/nix-build.cc#L218. and fixing it requires only using pkgs.runCommand instead; but it seems this behaviour was added intentionally; so although afaict it is not documented anywhere it might be that some users depend on it?

In either case, I do not think this should be the default behaviour, and it should certainly not be the only behaviour offered.

## Describe the bug Any invocation of `nix-shell -p <some-packages>` will always include `gcc` in the shell it builds. Usually this isn't much of an issue, but it can become very annoying on disk-space constrained machines, on machines with a slow connection to the cache, or if one wants to use another `cc` which will get shadowed by any `nix-shell`, with no hint on that in the documentation (or at least none that i could find). In particular, even `nix-shell -p clang` will still also include a `gcc`. An issue was filed on this for nix a while ago, but got no response: https://github.com/NixOS/nix/issues/5117 ## Steps To Reproduce ~~~ ❯ nix-shell -p hello --pure --command "cc --version" gcc (GCC) 13.2.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ~~~ ## Expected behavior The above should result in `cc: command not found`. ## `nix --version` output ~~~ nix (Lix, like Nix) 2.90.0-lix ~~~ ## Additional context This is caused by using `pkgs.runCommandCC` in the templated nix expression used for `-p` in https://git.lix.systems/lix-project/lix/src/branch/main/src/nix-build/nix-build.cc#L218. and fixing it requires only using `pkgs.runCommand` instead; but it seems [this behaviour was added intentionally](https://git.lix.systems/lix-project/lix/commit/9b63bb88c8873d192b8b01608e5d230817dd3375); so although afaict it is not documented anywhere it might be that some users depend on it? In either case, I do not think this should be the default behaviour, and it should certainly not be the *only* behaviour offered.

stuebinm added the

bug

label 2024-06-06 23:33:40 +00:00

qyriad commented

2024-06-07 02:34:13 +00:00

Owner

This is because nix-shell -p uses pkgs.mkShell under the hood, which is a wrapper around stdenv.mkDerivation, and thus always gives you stdenv.cc (GCC on Linux).

Making nix-shell -p use pkgs.mkShellNoCC would be a breaking change, and frankly this command is cursed to begin with, but we could maybe make it use mkShellNoCC as a config option or something? And make that the default in 3.0?

This is because `nix-shell -p` uses `pkgs.mkShell` under the hood, which is a wrapper around `stdenv.mkDerivation`, and thus always gives you `stdenv.cc` (GCC on Linux). Making `nix-shell -p` use `pkgs.mkShellNoCC` would be a breaking change, and frankly this command is cursed to begin with, but we could maybe make it use `mkShellNoCC` as a config option or something? And make that the default in 3.0?

qyriad commented

2024-06-07 02:35:35 +00:00

Owner

Oh oops we missed the whole part about runCommandCC and we were slightly wrong — sorry about that 😅. I agree that this is silly behavior, but changing it by default is a bit fraught

Oh oops we missed the whole part about `runCommandCC` and we were slightly wrong — sorry about that 😅. I agree that this is silly behavior, but changing it by default is a bit fraught

qyriad added

docs

and removed

bug

labels 2024-06-07 02:37:11 +00:00

pennae commented

2024-06-07 10:52:53 +00:00

Owner

we'd prefer to fix this in cooperation with nixpkgs, by having nixpkgs add a variant of mkShell that behaves like runCommandCC does currently except that the tools implicit pulled in by the *CC bit print warnings when used. that shouldn't take any longer to become evident (since such a new variant would be backportable), and when we eventually do switch the default it'll have been visible for a while?

we'd prefer to fix this in cooperation with nixpkgs, by having nixpkgs add a variant of `mkShell` that behaves like `runCommandCC` does currently except that the tools implicit pulled in by the `*CC` bit print warnings when used. that shouldn't take any longer to become evident (since such a new variant would be backportable), and when we eventually do switch the default it'll have been visible for a while?

qyriad commented

2024-06-07 18:12:57 +00:00

Owner

Do you mean something other than mkShellNoCC?

Do you mean something other than `mkShellNoCC`?

pennae commented

2024-06-07 18:24:04 +00:00

Owner

yes; we'd like to have a loud warning about using cc from `nix-shell -p` without an explicit compiler package being requested is deprecated when anything uses cc or something like that, while mkShellNoCC just doesn't have a compiler at all. we actually use this implicit-cc behavior of nix-shell quite a bit and suspect others might too, and a lix-level warning would be annoying to all those who don't

but idk. just want to Very Avoid breaking this without adequate warning :/

yes; we'd like to have a loud warning about ``using cc from `nix-shell -p` without an explicit compiler package being requested is deprecated`` when anything *uses* `cc` or something like that, while `mkShellNoCC` just doesn't have a compiler at all. we actually use this implicit-cc behavior of nix-shell quite a bit and suspect others might too, and a lix-level warning would be annoying to all those who don't but idk. just want to Very Avoid breaking this without adequate warning :/

jade commented

2024-06-07 22:06:39 +00:00

Owner

we also use this extensively ourselves but concur it's very silly it's not selectable. it's not just a cc that you need, you also need a binutils and such, which nix shell actually can't do at present at all. it's a multi layered pile of sadness.

we also use this extensively ourselves but concur it's very silly it's not selectable. it's not just a cc that you need, you also need a binutils and such, which `nix shell` actually can't do at present at all. it's a multi layered pile of sadness.

lunaphied removed the

label 2024-07-07 19:34:29 +00:00

lunaphied added the

label 2024-07-07 19:36:49 +00:00

No milestone

No project

No assignees

4 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#377

No description provided.

nix-shell -p always includes a gcc #377

Describe the bug

Steps To Reproduce

Expected behavior

nix --version output

Additional context

`nix --version` output