diff options
agentic ai; is so; fucking cool; omgmain
Diffstat (limited to 'docs/archive/faqs.html')
| -rw-r--r-- | docs/archive/faqs.html | 469 |
1 files changed, 469 insertions, 0 deletions
diff --git a/docs/archive/faqs.html b/docs/archive/faqs.html new file mode 100644 index 0000000..05be2d8 --- /dev/null +++ b/docs/archive/faqs.html @@ -0,0 +1,469 @@ +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> + <head> + <meta charset="utf-8"> + <meta name="generator" content="Docutils 0.22.4: https://docutils.sourceforge.io/"> + <meta name="viewport" content="width=device-width, initial-scale=1"> + <meta content="nixtamal, faqs, frequently asked questions, information" name="keywords"> + <meta content="Answers some of your questions about Nixtamal" name="description"> + <meta content="toastal" name="author"> + <meta content="" name="robots"> + <title> + Frequently asked questions | Nixtamal + </title> + <meta name="generator" content="soupault"> + <meta name="viewport" content="width=device-width,initial-scale=1"> + <meta http-equiv="X-XSS-Protection" content="1;mode=block"> + <meta http-equiv="X-Content-Type-Options" content="nosniff"> + <meta http-equiv="Content-Security-Policy" content="default-src 'self';"> + <meta http-equiv="Referrer-Policy" content="strict-origin-when-cross-origin"> + <meta name="theme" content="crimson"> + <link rel="icon" type="image/svg+xml" href="/asset/_hashed/nixtamal/image/nixtamal-logo-gmxzsw8388sf9paq05xws7an4hnl4nx0.svg"> + <link rel="stylesheet" href="/asset/_hashed/nixtamal/style/font-j47xx20z5d89qpsl95nnbipkg6d25m6y.css"> + <link rel="stylesheet" href="/asset/_hashed/sugilite256/chroma-light-yfrfnk1zyqm9dc67gaa5y67s0a6x40ji.css"> + <link rel="stylesheet" href="/asset/_hashed/sugilite256/chroma-dark-s4ssx3zwz2w418zx7pkrqlwqmywgvahl.css" media="(prefers-color-scheme: dark)"> + <link rel="stylesheet" href="/asset/_hashed/nixtamal/style/main-lmdn1rci18371fnrcqrwga636ip08irz.css"> + <link rel="author" href="/humans.txt"> + </head> + <body> + <div id="DocWrapper" class="DocWrapper"> + <div class="Banner-wrapper"> + <header id="Banner" class="Banner"> + <pre role="none" class="Banner-flair">âââ»+â» â±ââ³âââââ³ââââ» +ââââââââ¹ââ¹â£â«ââââ£â«â +â¹âââ¹â± â¹ â¹ â¹â¹â¹ â¹â¹â¹ââ</pre> + <a href="/" class="SiteLogo" title="Home"> + <svg viewbox="0 0 79.375 27.099415" class="SiteLogo-image" role="img" aria-labelledby="SiteLogo-desc"> + <use href="/asset/_hashed/nixtamal/image/nixtamal-logo-gmxzsw8388sf9paq05xws7an4hnl4nx0.svg#logo"> + <desc id="SiteLogo-desc"> + Home + </desc> + </use> + </svg> + </a> + <nav id="Navigation" class="Banner-navigation Navigation Navigation--banner" aria-expanded="true"> + <a class="Navigation-item" href="/install/">Install</a> + <a class="Navigation-item" href="/manpage/">Manpage</a> + <a class="Navigation-item" href="/changelog/">Changelog</a> + <a class="Navigation-item" href="/roadmap/">Roadmap</a> + <a class="Navigation-item" href="/cookbook/">Cookbook</a> + <a class="Navigation-item" href="/real-world-showcase/">Real-world showcase</a> + + <a class="Navigation-item" href="/community/">Community</a> + <a class="Navigation-item" href="/faqs/"><abbr title="frequently asked questions">FAQs</abbr></a> + <a class="Navigation-item" href="/funding/">Funding</a> + </nav> + </header> + <hr class="Banner-separator"> + </div> + <main id="Main" class="Main"> + <article id="Article" class="Article Stack"> + <header class="Headline Article-headline"> + <h1 itemprop="headline" class="title"> + Frequently asked questions + </h1> + </header> + <section itemprop="articleBody" id="Content" class="Content Article-body"> + <div class="details"> + <details> + <summary> + How to pronounce âNixtamalâ? + </summary> + <p> + <strong>/nɪÊ.tÉËmal/</strong> <em>or</em> <strong>/ËnɪkstÉËmÉËl/</strong> + </p> + <p> + The Nahuatl pronunciation is a bit better, but no qualms with an anglicized pronunciationâââas folks are probably used to Nix as /Ënɪks/. + </p> + <p> + Additionally, ·ð¯ð¦ððð©ð¥ðð¤ is a valid spelling for <code>en-Shaw</code>. + </p> + </details> + <details> + <summary> + What does the name mean? + </summary> + <figure class="Quoteblock"> + <blockquote> + <p> + : limed kernels of [maize] that is ready to be ground into masa + </p> + </blockquote> + <figcaption> + ââMerriam-Webster, <cite><a class="reference external" href="https://www.merriam-webster.com/dictionary/nixtamal">nixtamal</a></cite> + </figcaption> + </figure> + <p> + This loosens the maizeâs outer hull, so it grinds easier & feeds you betterâââmaking it key to Mesoamerican food & health. + </p> + </details> + <details> + <summary> + What is âfreshnessâ? + </summary> + <p> + The dual to <em>fresh</em> is <em>stale</em>. Is your input <em>stale</em>? Letâs check the <code>fresh-cmd</code> to find out! + </p> + <p> + The word âlatestâ wasnât quite appropriate since itâs up the user to decide what <em>fresh</em> means for their contextâââwhich often isnât âlatestâ. +The idea is: so long as it can be executed in your shell & returns a string that can be compared against, you can write honestly whatever you want. +This also pairs well with the command named <code>nixtamal refresh</code> (same as <code>pkcon refresh</code>) which runs the <code>fresh-cmd</code> which can short-circuit trying to prefetch your input to prevent wasteful network usage to download inputs or getting versions you donât want (itâs your logic). + </p> + </details> + <details> + <summary> + Can I get <code>$X</code> fetcher supported? How to add a fetcher? + </summary> + <p> + We donât believe it is in this projectâs or the Commonsâ interest to carve out special support for any fetchers (patches had to do this for <code>fetchpatch2</code>, but this was to enable a broader feature). +What you should do is submit a patchset to upstream Nixpkgs with your fetcherâââideally with <abbr title="JavaScript Object Notation">JSON</abbr> support like the others along with being added to <code>pkgs.nix-prefetch-scripts</code>. +This enables <em>Nix community</em> to have access to your prefetcher, not just Nixtamal which would be selfishly hoarding that capability. +Once it is merged, ping me & we can write or help you write the code needed. + </p> + </details> + <details> + <summary> + Isnât Nixpkgs big/overkill to do pinning? + </summary> + <p> + Big, yes. +Overkill⦠itâs not as simple. +In order to get access to the fetchers, one would need to bootstrap their setup & build their own <code>derivation</code>. +This includes at minimum a C compiler & some form of <code>coreutils</code>⦠except you need more than this. +For instance if you want to use <code>pkgs.fetchdarcs</code> or even create your own, you need a Darcs binary, which requires the Haskell tooling (or all static binaries built for specific platforms). +When you take a look at how that would be set up, you would effectively be reimplementing Nixpkgs. +As such, the simpler answer is to say Nixpkgs is effectively <em>required</em>. +We can giggle about the size of that dependency, but the reality is 98% of projects using Nix are going to be using Nixpkgs anyhow. +Nixtamal does offer configuration when <code>import</code>ing it which can be used to provide a minimal package set if needed. +Wishful thoughts would be that if Nixpkgs werenât so monolithic, core features like compilers & fetchers could be separate from general packaging, but where these lines get drawn are neither clear nor simple. + </p> + </details> + <details> + <summary> + Why OCaml as the main programming language? + </summary> + <p> + Nix the programming language falls in the <a class="reference external" href="https://en.wikipedia.org/wiki/ML_(programming_language)">ML</a> family & share a lot of syntax & conventions with other functional languages in the family. +This makes the code more approachable to those familiar with Nix rather than needing to learn a very different language like Npins (Rust) or Yae (Go). +The compile times are fast & the ecosystem is sufficient. + </p> + </details> + <details> + <summary> + Why <a class="reference external" href="https://kdl.dev"><abbr title="KDL Document language">KDL</abbr></a> for the manifest language? + </summary> + <p> + <abbr title="KDL Document language">KDL</abbr> has a syntax that isnât a burden to use a configuration languageâââwhich helps explain why is very popular for its age. +<abbr title="JavaScript Object Notation">JSON</abbr> has no comments, one must watch commas, & is verbose with quotations. +<abbr title="Tomâs Obvious, Minimal Language">TOML</abbr> doesnât nest well. +<abbr title="Yet Another Markup Language">YAML</abbr> is overly complex. +Nickel is great, but needs to be transformed into one of these others. +<abbr title="Extensible Data Notation">EDN</abbr> was considered, but <abbr title="KDL Document language">KDL</abbr> felt better to writeâââespecially the <code>fresh-cmd</code> syntax using <code>$</code> & <code>|</code> as node names. +<abbr title="KDL Document language">KDL</abbr> has a schema language & a best-attempt schema.kdl should be shipped as well for future <abbr title="KDL Document language">KDL</abbr> tooling or <abbr title="large language model">LLM</abbr> assistance. + </p> + </details> + <details> + <summary> + Why even have a manifest file at all? + </summary> + <p> + Have you ever needed to switch branches on an input to something stable or next to get code working? +The reality is your inputs evolve over time. +If you have ever used <code>flake.nix</code>âs <code>inputs</code> you probably had a good experience of say changing a Git inputâs <code>?ref=â¦</code> to point to a different branch/revision. +These <abbr title="command-line interface">CLI</abbr>-only options donât make this a nice experienceâyou either need to know the input key name to upsert it at the new reference point or you had to go spelunking in the lockfile (meaning you needed to be wary of <abbr title="JavaScript Object Notation">JSON</abbr> rules, but also wasnât the lockfile supposed to be machine-generated⦠& why do these lockfiles have data unrelated to locking?). +The reality is that <em>betting on text</em> has been a long-standing practice for a reason. +In the long run, a manifest file makes changing reference points, adding patches, changing hash algorithms easierâas well as being easier for humans (& prehaps <abbr title="large language model">LLM</abbr>s) to understand. + </p> + </details> + <details> + <summary> + Why not <abbr title="KDL Document language">KDL</abbr> for the lockfile? + </summary> + <p> + Nix does does not have a <code>builtins.fromKDL</code> (tho there has been <a title="Beware: this hyperlink will take you to GitHub, a proprietary code forge owned by a US-based, publicly-traded megacorporation, Microsoft which is using your data to train AIs & then sell it back to you" class="bad-proprietary reference external" href="https://github.com/NixOS/nixpkgs/pull/426828">some rumblings for formats.kdl in Nixpkgs</a>). +As such your options are <code>builtins.fromJSON</code> or <code>builtins.fromTOML</code> & the Rust communityâs obsession with <abbr title="Tomâs Obvious, Minimal Language">TOML</abbr> & that <abbr title="Tomâs Obvious, Minimal Language">TOML</abbr> needs to integrate <abbr title="JavaScript Object Notation">JSON</abbr> syntax anyway (just like <abbr title="Yet Another Markup Language">YAML</abbr>), it tips the scales in <abbr title="JavaScript Object Notation">JSON</abbr>âs favor. + </p> + </details> + <details> + <summary> + Why is the project using <a class="reference external" href="https://darcs.net"><abbr title="Darcs Advanced Revision Control System">Darcs</abbr></a> & not Git? + </summary> + <p> + <a class="reference external" href="https://darcs.net/Theory">Patch Theory</a> is cool where patches commute (order doesnât matter) which eliminates an entire set of merge conflicts present in snapshot-based <abbr title="version control system">VCS</abbr>s. +Pijul has the same theory behind it, is faster, & the new identity concept is what should have been (instead of name + email burned in the commits), but still lacks tooling. +By using <abbr title="Darcs Advanced Revision Control System">Darcs</abbr>, we can also <a class="reference external" href="https://en.wikipedia.org/wiki/Eating_your_own_dog_food">dogfood</a> support for Nixtamal. +Git uses an arcane, obtuse <abbr title="command-line interface">CLI</abbr> commands that everyone knows is overly complicated & inconsistent, so why not try something fundamentally different? + </p> + <p> + However, <em>do not</em> be surprised if this project moves to Pijul if the tooling gets better since Darcs has been tested well enough, which would mean it would be Pijulâs turn next! +<abbr title="Darcs Advanced Revision Control System">Darcs</abbr> is still worked on albeit it slower, but it also has some warts time has left on it. +If there is a simple, self-hostable <abbr title="Hypertext Transfer Protocol">HTTP</abbr> option for the server & a better story for rebase, <a itemprop="url" href="https://toast.al"><span itemtype="https://schema.org/Person" itemscope="" class="peer"><span itemprop="name">toastal</span></span></a> could switch. + </p> + </details> + <details> + <summary> + Will the project make a Git mirror? + </summary> + <p> + No. +This defeats the purpose of dogfooding actual alternative <abbr title="version control system">VCS</abbr>s. +If you see a Git mirror, itâs 100% unofficialâââif not illegitimate. + </p> + </details> + <details> + <summary> + What is wrong with with forge-specific <abbr title="uniform resource locator">URL</abbr> schemes or semantics? + </summary> + <p> + Trends shiftâââwhatâs beloved now likely wonât be tomorrow. +Rather than a minor convenience for what is popular now, a better design is to not give any place special privilege. +This special privilege can make folks feel peer pressured into using the current trend platform (<em>especially</em> <a class="reference external" href="https://mako.cc/writing/hill-free_tools.html">proprietary code forges for free software</a>). +We donât want to foster this behaviorâââno, we want to see more self-hosting where a code base is truly owned by its makers, even if just for a backup mirror. +This also lessens the maintenance burden as <abbr title="Application Programming Interface">API</abbr>s shift & âmine tooâ-ing of someoneâs unsupported platform. + </p> + </details> + <details> + <summary> + How can I lock the <code>fresh-cmd</code> <abbr title="command-line interface">CLI</abbr> tools? + </summary> + <p> + This is on you & if this actually bothers you (since it might not, which we will get to). +In most cases, we would assume you will be using old stable toolsâââsuch as <code>curl</code>, <code>jq</code>, <code>htmlq</code>, <code>git</code>, <code>coreutils</code>âââwhich donât really change much in practice. +If you want, you can add these tools to your development shell & run <code>nixtamal â¦</code> from the shell. +You can also use something like <code>nix run</code> or <code>nix-run</code> in the <code>fresh-cmd</code>. +But is it so bad that this could be <em>*gasp*</em> âimpureâ? +What we mean by this is that the generated lockfile is still pure regardless after <code>fresh-cmd</code> is ranâââwhich is the part that really matters hereâââ& other than the maintainer, I wouldnât expect contributors or downstream to need to touch your <code>$NIXTAMAL_DIRECTORY</code>. + </p> + <p> + Also did you ever think about <code>nix flake update</code>? +This is usually ran with the whimsy of the Nix version that is on your system meaning something equally âbadâ or âbreakingâ could happen here. +Perhaps not even âequallyâ but potentially <em>worse</em>⦠as the <code>nix</code> binary is usually system-dependent & <code>flakes.nix</code> manifest file doesnât have a version so its behavior could be interpretted differently depending you & your teamâs versions being slightly out of sync. + </p> + </details> + <details> + <summary> + What is wrong with Nix flakes? + </summary> + <p> + Well this is a hairy topic that is sure to ruffle feathers⦠+First, we should address that flakes arenât just version pinning (Nixtamalâs current focus) but an enforced pattern of project layout & composition (or lack thereof depending on how you argue that). +So letâs focus on the differences from the context of input pinning for now⦠+Flakes might be âbuilt inâ, but it requires enabling an experimental flag; this might sound innocuousâââespecially given the prevelance of enabling it in the Nix communityâââbut it has some serious downsides. + </p> + <ul class="simple"> + <li> + <p> + Flakes were originally designed for specific clientâs needs which might not match your own + </p> + </li> + <li> + <p> + Since itâs experimental, its manifest is not versioned (meaning no <code>version = "1.0.0";</code> in <code>flake.nix</code>) which ties the implementation to a version of Nix without a reasonable indicator to migrate or rollback to a version which leads can lead to unforeseen or catastrophic issues now that we are relying on the state of Nix executing it + </p> + </li> + <li> + <p> + Flakes have been largely âstableâ in so far as they are now a political topic meaning all proposals have been gridlocked on both bikeshedding & serious topics + </p> + </li> + <li> + <p> + âWeâll stablize soonâ¢â, has been going on since like 2023 + </p> + </li> + <li> + <p> + There have been multiple external efforts to stablize like Deteriminate Nix, Lix, & so forth, but now you are reliant on a specific fork for stability. Like how many projects claim to have a syntax that is âjust Markdownâ, but Markdown being underspecified for the task means each project maintains a fork of the syntax (sometimes disguised as âflavorâ). Just like the collisions you probably noticed trying to use the same Markdown file in 2 separately platforms, these flake forks will always be incompatible despite sharing <code>flake.nix</code> + <code>flake.lock</code> files + </p> + </li> + <li> + <p> + Being built-in & not a third-party tool or pattern makes it harder to fork it reasonably & also stifles diversity & innovation as other options will be seen as more friction even if offering something simpler since an extra tool is involed + </p> + </li> + </ul> + <p> + Outside of the experimental nature we have other issue that affect pinning: + </p> + <ul class="simple"> + <li> + <p> + We are limited to the built-in fetchers/fetch-tree & if you read the bug tracker for <code>nix</code> they donât seem terribly interested in adding more fetcher support since they already have a lot to maintainâââincluding the burden of trying to maintain these shorthands for specific hosts; if you wanted it to support Darcs, Pijul, Fossil, or the next big <abbr title="version control system">VCS</abbr>, tough luck + </p> + </li> + <li> + <p> + The <abbr title="Uniform Resource Identifier">URI</abbr> scheme is nice until it isnâtâââwhere expressing more complexity become a subjectively unreadably-long string of query parameters + </p> + </li> + <li> + <p> + The <abbr title="Uniform Resource Identifier">URI</abbr> scheme doesnât support mirrors + </p> + </li> + <li> + <p> + Overlays offer better compositionality than <code>input.*.follows</code> but <code>follows</code> has been treated more as the preferred option, with many not exposing an overlay + </p> + </li> + <li> + <p> + Dependency explosion as all inputs are now added to your lock & fetched (not just the millons of separately-pinned <code>nixpkgs</code> if anyone in the chain forgot or canât use <code>follows</code>, but inputs that are just used for âdevelopmentâ, or largely useless ones like <code>flake-utils</code>âs <code>eachDefaultSystem</code> which hides the complexity of the Flake <abbr title="Application Programming Interface">API</abbr> in a dangerous way since the whole point was to be explicit about declaring what systems are supported); by providing an overlay you can skip this + </p> + </li> + <li> + <p> + Patching inputs are not intuitive & some really wild options like involving the module system have been proposed to try to deal with it + </p> + </li> + </ul> + <p> + If you want to know about flakes schema criticisms, you can ask other places ð + </p> + </details> + <details> + <summary> + But can I use Nixtamal <em>with</em> flakes? + </summary> + <p> + You are welcome to use Nixtamal inside a <code>flake.nix</code> to get access to the the better experience that new Nix <code>command</code> setting offers (which sadly just work better with flakes instead of being more generic). +In the basic/easiest case, you donât let flakes manage <code>inputs</code> anymore like: + </p> + <pre class="code nix literal-block"><span class="p">{</span> + <span class="c1"># No longer any need for inputs</span> + <span class="c1"># inputs = { };</span> + + <span class="n">outputs</span> <span class="o">=</span> + <span class="p">{</span> <span class="n">self</span> <span class="p">}:</span> + <span class="k">let</span> + <span class="n">inputs</span> <span class="o">=</span> <span class="kn">import</span> <span class="sr">./nix/tamal</span> <span class="p">{</span> <span class="p">};</span> + + <span class="n">pkgs</span> <span class="o">=</span> <span class="kn">import</span> <span class="n">inputs</span><span class="o">.</span><span class="n">nixpkgs</span> <span class="p">{</span> + <span class="n">system</span> <span class="o">=</span> <span class="s2">"x86_64-linux"</span><span class="p">;</span> + <span class="n">config</span> <span class="o">=</span> <span class="p">{</span> <span class="p">};</span> + <span class="n">overlay</span> <span class="o">=</span> <span class="p">[</span> <span class="p">(</span><span class="kn">import</span> <span class="s2">"</span><span class="si">${</span><span class="n">inputs</span><span class="o">.</span><span class="n">MY-PROJECT</span><span class="si">}</span><span class="s2">/nix/overlay"</span><span class="p">)</span> <span class="p">];</span> + <span class="p">};</span> + <span class="k">in</span> + <span class="p">{</span> + <span class="c1"># â¦</span> + <span class="p">};</span> +<span class="p">}</span></pre> + <p> + If you want that <code>forAllSystem</code> function, you can build your own with builtins, or the standalone <a title="Beware: this hyperlink will take you to GitHub, a proprietary code forge owned by a US-based, publicly-traded megacorporation, Microsoft which is using your data to train AIs & then sell it back to you" class="bad-proprietary reference external" href="https://github.com/nix-community/nixpkgs.lib">nixpkgs.lib</a> mirror, or add <a title="Beware: this hyperlink will take you to GitHub, a proprietary code forge owned by a US-based, publicly-traded megacorporation, Microsoft which is using your data to train AIs & then sell it back to you" class="bad-proprietary reference external" href="https://github.com/numtide/flake-utils/">flake-utils</a>âââwhich <strong>now</strong> has a use case since we donât have access to Nixpkgs or <code>lib</code> (but donât blindly use <code>eachDefaultSystem</code>). +If this feels unergonomic, this is tradeoff for using flakesâââwhich has pros & cons against classic Nix as you must define upfront your supported systems (& you must do it correctly, meaning you donât declare systems you donât support or havenât tested <em>as well as</em> supporting all systems that are actually supported else users that <em>could</em> be supported have their ability to try removed). +Classic Nix, you let the downstream user decide (even unsafely) what <code>system</code> means & only <code>MY-PACKAGE.meta.platform</code> to assert system support. + </p> + <p> + Otherwise you could glue together some things from Nix flakes inputs + Nixtamal inputs: + </p> + <pre class="code nix literal-block"><span class="p">{</span> + <span class="n">inputs</span> <span class="o">=</span> <span class="p">{</span> + <span class="n">nixpkgs</span><span class="o">.</span><span class="n">url</span> <span class="o">=</span> <span class="s2">"github:NixOS/nixpkgs/nixos-unstable"</span><span class="p">;</span> + <span class="n">OTHER-FLAKE</span><span class="o">.</span><span class="n">url</span> <span class="o">=</span> <span class="s2">"hg+https://some.dev/project"</span><span class="p">;</span> + <span class="c1"># â¦more inputs</span> + <span class="p">};</span> + + <span class="n">outputs</span> <span class="o">=</span> + <span class="p">{</span> + <span class="n">self</span><span class="o">,</span> + <span class="n">nixpkgs</span><span class="o">,</span> + <span class="n">OTHER-FLAKE</span><span class="o">,</span> + <span class="p">}:</span> + <span class="k">let</span> + <span class="n">inputs</span> <span class="o">=</span> <span class="kn">import</span> <span class="sr">./nix/tamal</span> <span class="p">{</span> <span class="n">bootstrap-nixpkgs</span> <span class="o">=</span> <span class="n">nixpkgs</span><span class="p">;</span> <span class="p">};</span> + + <span class="n">pkgs</span> <span class="o">=</span> <span class="kn">import</span> <span class="n">nixpkgs</span> <span class="p">{</span> + <span class="n">system</span> <span class="o">=</span> <span class="s2">"x86_64-linux"</span><span class="p">;</span> + <span class="n">config</span> <span class="o">=</span> <span class="p">{</span> <span class="p">};</span> + <span class="n">overlay</span> <span class="o">=</span> <span class="p">[</span> + <span class="p">(</span><span class="kn">import</span> <span class="s2">"</span><span class="si">${</span><span class="n">inputs</span><span class="o">.</span><span class="n">MY-PROJECT</span><span class="si">}</span><span class="s2">/nix/overlay"</span><span class="p">)</span> + <span class="p">(</span><span class="kn">import</span> <span class="n">OTHER-FLAKE</span><span class="o">.</span><span class="n">overlays</span><span class="o">.</span><span class="n">default</span><span class="p">)</span> + <span class="p">];</span> + <span class="p">};</span> + <span class="k">in</span> + <span class="p">{</span> + <span class="c1"># â¦</span> + <span class="p">};</span> +<span class="p">}</span></pre> + </details> + <details> + <summary> + Does Nixtamal resolve recursive inputs? + </summary> + <p> + No. +Could it? +Maybe. +Is it a good idea? +Ehhhh⦠+There is a lot of convenience that comes from recursive solving, but it relies on some implicit downloading behavior that can be harder to follow if not audit for security. +You wouldnât want to be like Nix flakes & download a million <code>nixpkgs</code> instances⦠nor is emulating <code>follows</code> the right design. +Stacking overlays might be the easier decision. + </p> + <figure class="Quoteblock"> + <blockquote> + <p> + But couldnât the overlays get out of sync with my one Nixpkgs pin? + </p> + </blockquote> + <figcaption> + ââAstute user + </figcaption> + </figure> + <p> + Yes, but this same thing happens when you <code>follows.nixpkgs</code> as many forget. +You can leave one input as <em>not</em> following & now get the aforementioned <code>nixpkgs</code> explosion issue potentially. +With Nixtamal, you would do a second Nixpkgs import <em>explicitly</em>, say in your <code>release.nix</code>, rather than implicitly, or will have to find another way to stitch it all together (you can even use Nixtamalâs patches feature to patch up their code!). +All to say that this isnât really âsolvedâ by anything today. +Recursive inputs wonât be a near-term focus either unless the ð¡ really goes off. + </p> + </details> + <details> + <summary> + I like Nix flakes better. + </summary> + <p> + Not a question, but okay. +You may continue to use flakes. +You wonât be the target audienceâââwhich is stable Nix users, users not requiring the extra abstraction complexity + hassle of flakes, & users that want features flakes can never support given the current design limitations. + </p> + </details> + </div> + </section> + </article> + </main> + <footer id="Footer" class="Footer"> + <p> + Site made with <a href="https://nixos.org">Nix</a> (<abbr title="dependency">dep</abbr> management), <a href="https://nickel-lang.org">Nickel</a> (<abbr title="configuration">config</abbr>), <a href="https://soupault.net">Soupault</a> (<abbr title="static site generator">SSG</abbr>), <a href="https://docutils.sourceforge.io">Docutils</a> (<abbr title="reStructuredText">rST</abbr> rendering), <a href="https://mandoc.bsd.lv">mandoc</a> (manpage conversion), & <a href="https://hub.darcs.net/toastal/sugilite256">sugilite256</a> (color scheme). + </p> + <small class="Footer-copyright"> + © 2025â2026 <span itemtype="https://schema.org/Person" itemscope=""><a itemprop="url" href="https://toast.al"><span itemprop="name">toastal</span></a></span>. + © 2026 Nixtamal contributors. + Some rights reserved. + Except where otherwise noted, the content on this website is licensed under <abbr title="Creative Commons Attribution Share Alike 4.0 International">CC-BY-SA-4.0</abbr>. + Citations must attribute the workâs writer/maker & include a hyperlink to this website (or rather the work itself). + Yes, these rules/clauses apply to <abbr title="large language models">LLM</abbr>s & <abbr title="artificial intellegence">AI</abbr> assistants too. + </small> + <div id="Maker" itemscope="" itemtype="https://schema.org/Person"> + <link itemprop="url" href="https://toast.al/"> + <meta itemprop="name" content="toastal"> + <meta itemprop="foundingDate" content="2025"> + <link itemprop="logo" href="https://nixtamal.toast.al/asset/_hashed/nixtamal/image/nixtamal-logo-gmxzsw8388sf9paq05xws7an4hnl4nx0.svg"> + <div itemprop="address" itemscope="" itemtype="https://schema.org/PostalAddress"> + <meta itemprop="addressCountry" content="TH"> + </div> + <link itemprop="sameAs" href="https://keybase.io/toastal"> + <link itemprop="sameAs" href="https://liberapay.com/toastal/"> + <link itemprop="sameAs" href="https://types.pl/@toastal"> + <link itemprop="sameAs" href="https://hub.darcs.net/toastal"> + <link itemprop="sameAs" href="https://smeder.ee/~toastal"> + <link itemprop="sameAs" href="https://nest.pijul.com/toastal"> + <link itemprop="sameAs" href="https://codeberg.org/toastal/"> + <link itemprop="sameAs" href="https://git.sr.ht/~toastal/"> + <link itemprop="sameAs" href="https://gitlab.com/toastal"> + <link itemprop="sameAs" href="https://github.com/toastal"> + </div> + </footer> + </div> +</body> +</html> |