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
-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: