Inaccurate statement regarding FOD's

[tejing1]

This:

nix-book/src/ch04-00-derivations.md

Lines 15 to 16 in f6448f4

	These are the "leaves" of any build closure, in that, they do not refer to other
	derivations. These derivations are defined by

isn't actually true. pkgs.fetchurl {...} refers to pkgs.curl, for example.

[jonringer]

it is true for builtins.fetch*.

Although nixpkgs has it's own variants of fetchers, I think the intuition is still correct. The derivation may have references to other derivations for realization, but once realized, the output will never have any dependencies.

I guess the confusion would be build vs "runtime" dependencies. FODs should never have any runtime dependencies, they are just content.

What would be a better way to word this?

[tejing1]

it is true for builtins.fetch*.

Strictly speaking, those aren't FODs, since afaik they don't involve a .drv file at all, but I definitely get the intuition behind this.

Although nixpkgs has it's own variants of fetchers, I think the intuition is still correct. The derivation may have references to other derivations for realization, but once realized, the output will never have any dependencies.

I guess the confusion would be build vs "runtime" dependencies. FODs should never have any runtime dependencies, they are just content.

It's true they are leaves of the runtime dependency graph (though in practice they're seldom in it at all), but in context, I don't see how it could be interpreted that way. The whole discussion is about the build closure.

What would be a better way to word this?

Maybe just move to the subject of intent rather than implementation, and say that FODs are the starting points from which you build software?

[jonringer]

Maybe just move to the subject of intent rather than implementation, and say that FODs are the starting points from which you build software?

Fair enough

[jonringer]

It's true they are leaves of the runtime dependency graph (though in practice they're seldom in it at all)

Yea, poor word choice on my part. I meant they get pruned after they get realized. So when they are consumed for a build, it's "just" the content.

[tejing1]

I meant they get pruned after they get realized.

It took me a few goes at this before I caught precisely what you mean. You're viewing the build closure as a dynamic object, which is pruned as derivations are realized, until it eventually becomes the runtime closure? In that context, FODs have the fairly uncommon property that upon realization all their children disappear.

I never particularly considered the dynamic picture, and only looked at the initial build closure and the final runtime closure as static objects.

[jonringer]

In that context, FODs have the fairly uncommon property that upon realization all their children disappear.

Yea, technically you could try multiple fetchers, one using git, one using http, another using some other protocol. And as long as they can all produce the same content, it's not relevant for the consuming derivation to know which one was used. Just that the content is available.

The build dependencies are an "implementation" detail. Or at least with how I view FODs. Maybe I'm wrong :)