docs: add tutorial for overriding package versions#447
docs: add tutorial for overriding package versions#447
Conversation
github-actions
bot
added
the
documentation
Walk through the end-to-end workflow of using overrideAttrs to get a newer version of a package before it's available in the Flox Catalog — from writing the Nix expression through building, publishing, and installing the override. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
djsauble
force-pushed
the
tutorial/overriding-packages
branch
from
a6df6d8 to
9b6bcb6
Compare
| The Flox Catalog tracks [nixpkgs][nixpkgs], which means there can be a | ||
| short delay between an upstream release and its availability in | ||
| the catalog. |
There was a problem hiding this comment.
We should link to the stabilities doc page here because it's not obvious what "tracking nixpkgs" means in practice (which branch, channel, cadence)
There was a problem hiding this comment.
Added a link to the Base Catalog page right after the nixpkgs mention.
| Rather than waiting for the catalog to catch up, you'll | ||
| override the package to use the newer release. |
There was a problem hiding this comment.
Wording, I'd like to avoid saying overriding a package.
My understanding of packages is that those are the final built artifacts. At this point we would be talking about overriding the recipe producing the package. (Or possibly more orecisely we create a new recipe from an existing one but tha might be splitting hairs.$
There was a problem hiding this comment.
Good call — reworded throughout to say "build recipe" instead of "package" when referring to what gets overridden.
| Let's set that up and publish: | ||
|
|
||
| ```text | ||
| $ git remote add origin "$PWD" |
There was a problem hiding this comment.
I'd consider this a huge anti pattern for our own good.
There was a problem hiding this comment.
I'm trying to keep the tutorial as self-contained as possible, which is why I'm not walking people through the process of creating a GitHub repository and adding it as a remote.
But we could add a note above this section (and maybe a comment inline as well) calling this out as an anti-pattern and telling people what they should do instead.
There was a problem hiding this comment.
Added a warning admonition before the code block calling out the $PWD remote as a simplification, and removed the softer note that was after it.
- Link to Base Catalog page for context on nixpkgs tracking (ysndr) - Reword "override the package" to "override the build recipe" (ysndr) - Add note about attribute differences across packages (jbayer) - Move $PWD anti-pattern warning before the code block (ysndr) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3 participants
Preview: https://7b3090989ba86e5ccb0be2917ee4f84f5544bdfa--floxdocs.netlify.app/docs/tutorials/overriding-packages/
docs/tutorials/overriding-packages.md) walking through the end-to-end workflow of usingoverrideAttrsto get a newer version of a package before it's available in the Flox Catalogmkdocs.ymlafter "Building and publishing packages"