From 39ec37c16762a95fac4b74df2fa2f12ec7d70eff Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Mon, 5 Oct 2020 09:32:18 -0300 Subject: swift2nix post: Fix spelling and grow dictionary --- _posts/2020-10-05-swift2nix-run-swift-inside-nix-builds.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to '_posts') diff --git a/_posts/2020-10-05-swift2nix-run-swift-inside-nix-builds.md b/_posts/2020-10-05-swift2nix-run-swift-inside-nix-builds.md index 3173165..e2368ad 100644 --- a/_posts/2020-10-05-swift2nix-run-swift-inside-nix-builds.md +++ b/_posts/2020-10-05-swift2nix-run-swift-inside-nix-builds.md @@ -82,7 +82,7 @@ part is important: it should be data, not code, otherwise you're back in the same problem, just like lockfiles are just data. Those work in any language, and tools can cooperate happily. -There's no need for this declarative expectation to be standartized, or be made +There's no need for this declarative expectation to be standardized, or be made compatible across languages. That would lead to a poor format that no package manager really likes. Instead, If every package manager could say out loud what it wants to see exactly, than more tools like swift2nix could exist, and they @@ -101,7 +101,7 @@ usually have fuzzy boundaries and tight coupling between: version; 2. generating a lockfile with the exact pinned versions; 3. downloading the dependencies present on the lockfile into some local cache; -4. arranging the dependencies from the cache in a meaniful way for itself inside +4. arranging the dependencies from the cache in a meaningful way for itself inside the project; 5. work using the dependencies while *assuming* that step 4 was done. @@ -123,7 +123,7 @@ Instead a much saner approach could be: The point is just making what the package manager requires visible to the outside world via some declarative data. If this data wasn't provided, it can -move on to doing its own automagic things. +move on to doing its own automatic things. By making the expectation explicit and public, one can plug tools *à la carte* if desired, but doesn't prevent the default code path of doing things the exact @@ -138,7 +138,7 @@ inside Nix". The avoidance of an "easy" interface that I mentioned above comes from me fighting with some of the "\*2nix" tools much like I have to fight with package -managers: I don't want to offload all build responsabilities to the "*2nix" +managers: I don't want to offload all build responsibilities to the "*2nix" tool, I just want to let it download some of the dependencies and get out of the way. I want to stick with `npm test` or `cargo build`, and Nix should only provide the environment. @@ -161,7 +161,7 @@ and reproducibility that Nix provides. It is even less brittle: any changes to how NPM runs some things will be future-compatible, since node2nix isn't trying to replicate what NPM does, or fiddling with NPM's internal. -**A "*2nix" tool should build the environment, preferebly from the lockfile +**A "*2nix" tool should build the environment, preferably from the lockfile directly and offload everything else to the package manager**. Everything else is just nice-to-have. -- cgit v1.2.3