mirror of
https://github.com/NixOS/rfcs.git
synced 2025-12-20 07:51:18 +01:00
Last (?) rephrasings
This commit is contained in:
Doron Behar
parent
0b259fa7f5
commit
d75c73ef9f
1 changed files with 38 additions and 38 deletions
|
|
@ -44,17 +44,16 @@ the environments to make the transition easier to review.
|
|||
|
||||
@rnhmjoj & @timokau How unfortunate it is that Python's `buildEnv` doesn't know
|
||||
to do anything besides setting `NIX_PYTHONPATH` - it knows nothing about other
|
||||
env vars, which is totally legitimate for dependencies of the environment to
|
||||
rely upon runtime. Declarative wrappers don't care about the meaning of env
|
||||
vars - all of them are treated equally, considering all of the inputs of a
|
||||
derivation equally.
|
||||
env vars, which some deps rely upon when eventually used. Declarative wrappers
|
||||
don't care about the meaning of env vars - all of them are treated equally,
|
||||
considering all of the inputs of a derivation equally.
|
||||
|
||||
- [pull 75851](https://github.com/NixOS/nixpkgs/pull/75851)
|
||||
- [issue 87667](https://github.com/NixOS/nixpkgs/issues/87667)
|
||||
|
||||
Fixable with our current wrapping tools (I guess?) but it's unfortunate that we
|
||||
have to trigger a rebuild of VLC and potentially increase it's closure size,
|
||||
just because of a missing env var for some users. If only our wrapping
|
||||
just because of a missing env var for only _some_ users. If only our wrapping
|
||||
requirements were accessible via Nix attrsets, we could have instructed our
|
||||
modules to consider this information when building the wrappers of the packages
|
||||
in `environment.systemPackages`.
|
||||
|
|
@ -78,51 +77,52 @@ and
|
|||
|
||||
I guess we don't wrap HPLIP because not everybody want to use these binaries
|
||||
and hence want these GUI deps in their closure (if they were wrapped with a
|
||||
setup hook)? Declarative wrappers would allow some users to use the wrapped
|
||||
binaries and others not need it, via an override or a NixOS config flag,
|
||||
without triggering a rebuild of HPLIP itself.
|
||||
setup hook)? Declarative wrappers would allow _some_ users to use the wrapped
|
||||
binaries and others not to need this wrapping. Via an override or a NixOS
|
||||
config flag, without triggering a rebuild of HPLIP itself, these users would be
|
||||
easily satisfied.
|
||||
|
||||
## Orchestrating wrapping hooks
|
||||
|
||||
- [issue 78792](https://github.com/NixOS/nixpkgs/issues/78792)
|
||||
|
||||
@worldofpeace you are correct. All of these setup-hooks are a mess, but at
|
||||
least we have documented, yet not totally implemented this section of the
|
||||
manual
|
||||
@worldofpeace you are correct. All of these setup-hooks are a mess. At least we
|
||||
have documented, (yet not totally implemented) this section of the manual
|
||||
https://nixos.org/nixpkgs/manual/#ssec-gnome-common-issues-double-wrapped
|
||||
|
||||
Declarative wrappers will deprecate the usage of our shell based hooks and will
|
||||
wrap all executables automatically according to their needs, without requiring
|
||||
the contributor a lot of knowledge of the wrapping system.
|
||||
the contributor a lot of knowledge of the wrapping system. Also, double
|
||||
wrappings will become a problem of the past.
|
||||
|
||||
- [issue 86369](https://github.com/NixOS/nixpkgs/issues/86369)
|
||||
|
||||
@ttuegel I get the sense [you support this
|
||||
idea](https://github.com/NixOS/nixpkgs/issues/86369#issuecomment-626732191).
|
||||
But for anyone else interested, the issue is a bit complex, so once you'll read
|
||||
the design of this RFC, and see examples of what the POC implementation of
|
||||
declarative wrappers [is capable
|
||||
@ttuegel I get the sense [you support this idea of declarative
|
||||
wrappers](https://github.com/NixOS/nixpkgs/issues/86369#issuecomment-626732191).
|
||||
For anyone else interested in a summary, the issue is a bit complex, so once
|
||||
you'll read the design of this RFC, and see examples of what the POC
|
||||
implementation of declarative wrappers [is capable
|
||||
of](https://github.com/NixOS/nixpkgs/pull/85103#issuecomment-614195666), I hope
|
||||
you'll see how declarative wrappers can solve this issue.
|
||||
you'll see how declarative wrappers will solve this issue.
|
||||
|
||||
|
||||
## Issues _possibly_ fixable by declarative wrappers (?)
|
||||
|
||||
- [pull 61213](https://github.com/NixOS/nixpkgs/pull/61213)
|
||||
|
||||
I'm not sure what's the issue there. But, I'm sure that a Nix based builder of
|
||||
a Python environment should make it easier to control and alter if needed, what
|
||||
environment is used even by builders, not only user facing Python environments.
|
||||
I'm not sure what's the issue there. But, I'm sure that a declarative, Nix
|
||||
based builder of a Python environment, even if this environment is used only
|
||||
for a build, should make it easier to control and alter it's e.g `$PATH`.
|
||||
|
||||
- [issue 83667](https://github.com/NixOS/nixpkgs/issues/83667)
|
||||
|
||||
@FRidh I see no reason for Python deps of Python packages to need to be in
|
||||
`propagatedBuildInputs` and not regular `buildInputs`. I think this was done so
|
||||
in the past so it'd be easy to know how to wrap them? Declarative wrappers
|
||||
won't require runtime-env-requiring deps to be only in `propagatedBuildInputs`
|
||||
or `buildInputs` - it should pick such deps from both lists. Hence, (I think) it
|
||||
should be possible to make Python's static builds consistent with other
|
||||
ecosystems.
|
||||
`propagatedBuildInputs` and not regular `buildInputs` but please correct me if
|
||||
I'm wrong. I think this was done so in the past so it'd be easy to know how to
|
||||
wrap them? Declarative wrappers won't require runtime-env-requiring deps to be
|
||||
only in `propagatedBuildInputs` or `buildInputs` - it should pick such deps
|
||||
from both lists. Hence, (I think) it should be possible to make Python's static
|
||||
builds consistent with other ecosystems.
|
||||
|
||||
- [issue 86054](https://github.com/NixOS/nixpkgs/issues/86054)
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ $ nix why-depends -f. kdeconnect kdeframeworks.kconfigwidgets.dev
|
|||
```
|
||||
|
||||
Also similar (but possibly fixable by moving `gobject-introspection` to a
|
||||
different inputs list?
|
||||
different inputs list?):
|
||||
|
||||
```
|
||||
$ nix why-depends -f. beets gobject-introspection.dev
|
||||
|
|
@ -176,7 +176,7 @@ $ nix why-depends -f. beets gobject-introspection.dev
|
|||
|
||||
- [issue 60260](https://github.com/NixOS/nixpkgs/issues/60260)
|
||||
|
||||
General, justified complain about wrappers.
|
||||
General, justified complaint about wrappers.
|
||||
|
||||
- [issue 95027](https://github.com/NixOS/nixpkgs/issues/95027)
|
||||
- [issue 23018](https://github.com/NixOS/nixpkgs/issues/23018)
|
||||
|
|
@ -205,7 +205,7 @@ interface similar to
|
|||
[`wrapMpv`](https://github.com/NixOS/nixpkgs/blob/a5985162e31587ae04ddc65c4e06146c2aff104c/pkgs/applications/video/mpv/wrapper.nix#L9-L23)
|
||||
and
|
||||
[`wrapNeovim`](https://github.com/NixOS/nixpkgs/blob/a5985162e31587ae04ddc65c4e06146c2aff104c/pkgs/applications/editors/neovim/wrapper.nix#L11-L24)
|
||||
which will accept a single derivation or an array of them and it'll wrap all of
|
||||
which will accept a single derivation or an array of them and will wrap all of
|
||||
their executables with the proper environment, based on their inputs.
|
||||
|
||||
`wrapGeneric` should iterate recursively all `buildInputs` and
|
||||
|
|
@ -319,9 +319,9 @@ Perhaps our shell hooks _can_ be fixed / improved, and we could help make it
|
|||
easier to debug them via `NIX_DEBUG`. Then it might help us track down e.g why
|
||||
environment variables are added twice etc. Still though, this wouldn't solve
|
||||
half of the other issues presented here. Most importantly, the shell hooks rely
|
||||
upon being in the inputs during build of the original derivation, hence mere
|
||||
changes to an environment may trigger rebuilds that take a lot of time and
|
||||
resources from avarage users. See [this
|
||||
upon being in the inputs during build of the original derivation. Hence, mere
|
||||
requests for changes to an environment a wrapper sets, trigger rebuilds that
|
||||
take a lot of time and resources from average users. See [this
|
||||
comment](https://github.com/NixOS/nixpkgs/pull/88136#issuecomment-632674653).
|
||||
|
||||
# Unresolved questions
|
||||
|
|
@ -330,13 +330,13 @@ comment](https://github.com/NixOS/nixpkgs/pull/88136#issuecomment-632674653).
|
|||
The POC implementation does 1 thing which I'm most sure could be done better,
|
||||
and that's iterating **recursively** all `buildInputs` and
|
||||
`propagatedBuildInputs` of the given derivations. This is currently implemented
|
||||
via a recursive (Nix) function, that's prone to reach a state of infinite
|
||||
recursion. But this risk is currently mitigated using an array of packages we
|
||||
know don't need any env vars at runtime, and for sure are very much at the
|
||||
bottom of the list of very common inputs. This is implemented
|
||||
with a recursive (Nix) function, prone to reach a state of infinite recursion.
|
||||
This risk is currently mitigated using an array of packages we know don't need
|
||||
any env vars at runtime, and for sure are very much at the bottom of the list
|
||||
of all Nixpkgs' dependency graph. This part is implemented
|
||||
[here](https://github.com/NixOS/nixpkgs/pull/85103/files#diff-44c2102a355f50131eb8f69fb7e7c18bR75-R131).
|
||||
|
||||
There are other methods of doing this recursive search, but TBH I haven't yet
|
||||
There are other methods of doing this recursive search, but I haven't yet
|
||||
investigated all of them. For reference and hopefully for an advice, this need
|
||||
was requested by others and discussed at:
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue