Last (?) rephrasings

rfcs/0075-declarative-wrappers.md

@@ -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
+env vars, which some deps rely upon when eventually used. Declarative wrappers
-rely upon runtime.  Declarative wrappers don't care about the meaning of env
+don't care about the meaning of env vars - all of them are treated equally,
-vars - all of them are treated equally, considering all of the inputs of a
+considering all of the inputs of a derivation equally.
-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
+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,
+binaries and others not to need this wrapping. Via an override or a NixOS
-without triggering a rebuild of HPLIP itself.
+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
+@worldofpeace you are correct. All of these setup-hooks are a mess. At least we
-least we have documented, yet not totally implemented this section of the
+have documented, (yet not totally implemented) this section of the manual
-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
+@ttuegel I get the sense [you support this idea of declarative
-idea](https://github.com/NixOS/nixpkgs/issues/86369#issuecomment-626732191).
+wrappers](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
+For anyone else interested in a summary, the issue is a bit complex, so once
-the design of this RFC, and see examples of what the POC implementation of
+you'll read the design of this RFC, and see examples of what the POC
-declarative wrappers [is capable
+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
+I'm not sure what's the issue there. But, I'm sure that a declarative, Nix
-a Python environment should make it easier to control and alter if needed, what
+based builder of a Python environment, even if this environment is used only
-environment is used even by builders, not only user facing Python environments.
+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
+`propagatedBuildInputs` and not regular `buildInputs` but please correct me if
-in the past so it'd be easy to know how to wrap them? Declarative wrappers
+I'm wrong. I think this was done so in the past so it'd be easy to know how to
-won't require runtime-env-requiring deps to be only in `propagatedBuildInputs`
+wrap them? Declarative wrappers won't require runtime-env-requiring deps to be
-or `buildInputs` - it should pick such deps from both lists. Hence, (I think) it
+only in `propagatedBuildInputs` or `buildInputs` - it should pick such deps
-should be possible to make Python's static builds consistent with other
+from both lists. Hence, (I think) it should be possible to make Python's static
-ecosystems.
+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
+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
+requests for changes to an environment a wrapper sets, trigger rebuilds that
-resources from avarage users. See [this
+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
+with a recursive (Nix) function, prone to reach a state of infinite recursion.
-recursion. But this risk is currently mitigated using an array of packages we
+This risk is currently mitigated using an array of packages we know don't need
-know don't need any env vars at runtime, and for sure are very much at the
+any env vars at runtime, and for sure are very much at the bottom of the list
-bottom of the list of very common inputs. This is implemented
+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: