New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bash,texinfo: turn interactive versions into passthrus #44521
Conversation
aa0c100
to
dcc1064
Compare
Success on x86_64-linux (full log) Attempted: bash, texinfo Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: bash, texinfo Partial log (click to expand)
|
as the old names (```bashInteractive```) are going to be broken, maybe it is time to invent a more precise name which would not need to be explained? > ```bash.withNcurses``` ?
The problem with `bash.withNcurses` is that it's too specific. As I said in the OP, I want FHS environments and such to select `.interactive` when it's available automatically.
I.e.
- you put `Y` into nativeBuildInputs -> you get `Y.bin/Y.out` (`getBin`)
- you put `Y` into systemPackages -> you get `Y.interactive/Y.out` (`getInteractive`)
- you can get others by asking for them specifically, e.g. with `Y.out` in `systemPackages`
Using some variant of the `self` trick to provide packages with useful overrides as passthrus may be a good idea, though. If we want users to use attr names, then grouping package variants under the main package makes sense to me. Like `emacs.nox`, `git.full`, etc.
I would make a cleaner mechanism for it, though. Like we can make `callPackage` to supply `self` and `.override` override it, or something. Then most of this hackery wouldn't be needed.
ATM, however, this `let self` hackery is needed or else `texinfo` and `bash` will be rebuilt multiple times in for the `stdenv`, these packages are kinda special.
|
This makes things way too complicated in my opinion. Putting overrides as passthru attrs just hides the problem, not fixes it. I want us to get to a point where we can do:
The bash/bashInteractive & texinfo/texinfoInteractive are just needed for bootstrapping. Besides that there is no reason we can't just make the default package the fully featured thing that everyone wants. Doing this without breaking stdenv is tricky but I think it can be done with overrides. You would just need to override each bash/texinfo instance listed in darwin/linux stdenv with |
```
bashInteractive = bash;
texinfoInteractive = texinfo;
```
I see, I agree that that would be better than this.
But what are your general thoughts on the ideas expressed in my comment above?
|
New ideas I will implement and test later, this is closed in favor of eventually changing default |
Motivation for this change
This patchset is a part of a bigger patchset (that needs a bit more work) that adds
getInteractive
to the lib (or maybe not, that is a subject to change) and then uses that to build user-facing environments. I.e. you, as a user, won't need to ask yourself "Do I need specify Y or YInteractive here?" after applying that patchset, you just say "Y" and it will then select the appropriate one for every instance. E.g.bash
in FHS environments and NixOS shells will be automatically referenced asbash.interactive
.Notes
b51ef9ece59be09c466d84b5387e5534d1458d3a is related, but unrelated (it's actually a piece of
doCheck
patchset), bundled here for simplicity.I do
let self =
thing here instead of pushingself
attr fromall-packages.nix
because bothbash
andtexinfo
are used instdenv
stages. Doing this the other way like, e.g. python does, needs some really ugly changes to stdenv.Things done