new tutorial on vendoring dependencies with flox build

[barstoolbluz]

No description provided.

[mkenigs]

Do you want to add this page to the table of contents?

    - Package Priority: concepts/priority.md

[mkenigs]

I think it could be nice to make this table a bit more concise, and then put it as a cheatsheet closer to the top where there's currently the bulleted list Priority resolves these collisions:. That would make it easy to find for someone who just needs the really quick visible TLDR reminding them what valid values are and if higher or lower wins

Suggested change

	| Aspect | Detail |
	| ------ | ------ |
	| Default value | `5` |
	| Direction | Lower number = higher precedence |
	| Valid values | Integers (no fixed bounds) |
	| Common range | `1` through `10` |
	| Same-priority collision | Error — environment fails to build |
	| Scope | File paths only — doesn't affect resolution |
	| Aspect | Detail |
	| ------ | ------ |
	| Default value | `5` |
	| Direction | Lower number = higher precedence |
	| Valid values | Integers (negatives allowed) |

(are negatives allowed? Idk)

[mkenigs]

Not sure if we need to go into this much detail about nixpkgs?

Suggested change

	Nixpkgs provides convenience wrappers —
	`lib.meta.hiPrio` (sets priority to -10) and
	`lib.meta.lowPrio` (sets priority to 10) —
	but in Flox you set the integer directly in the manifest.

[mkenigs]

I like that this section includes the actual error - I wonder if it could be merged with this section above:

Most packages don't conflict, so you rarely need to think about priority. The situations where it matters are:

And I like that you use some actual examples throughout - I think dropping this packageA/packageB example and using thte same packages all the way through, starting with How priority works could be easier to follow

[mkenigs]

I think we might want to clarify the organization of a few things for this page.

The intro for this page says it covers missing dependency vendoring but not sandbox vendoring, but then it has a sandbox vendoring section ("Download in an impure build stage"). I'm also not sure we should cover using flake inputs on a vendoring dependencies page.

The "## Manifest builds" section has a "### Provide the dependency as a Nix expression build" subsection. But then there's a separate "## Nix expression builds" section

We also have a number of examples in the https://flox.dev/docs/concepts/nix-expression-builds/#what-can-you-build section that have some overlap with some of these examples. E.g. this page has "Override an existing package's version", that page has "Example: Newer version of an existing package." Seems like we should clarify where to look for what information, and also de-duplicate it.

We have "Example: Vendor an existing package" (which also needs to be updated to use flox build import-nixpkgs instead of nix edit) which overlaps with this page as a whole