Re: Direct symlink farm for transitive dependencies vs search paths

Re: Direct symlink farm for transitive dependencies vs search paths

[Adam Faiz]

> Let's say that A depends on B, and B depends on C.
> 
> With search paths, A doesn't have symlinks to B, and B doesn't have symlinks to 
> C. Thus, disk space is saved.
> 
> However, adding search path patches to existing softwares is cumbersome, and a 
> long list of search paths results in inefficient searches.
> 
> Let's assume that B has symlinks to C, and A has symlinks to everything in B. 
> This means A has symlinks to symlinks in B. Transitive symlink is probably more 
> efficient than search path. If A just copies symlinks from B and has symlinks 
> to plain files in B, then A ends up with only direct symlinks. Direct symlinks 
> are more efficient than transitive symlinks.
> 
> It seems that search paths are preferred over symlinks to transitive 
> dependencies in gnu guix. Why?
Search paths are preferred because their purpose is to provide a list of places to look for extensions/plugins/mods of a package. Essentially, search paths are a way to provide runtime dependencies that are optional.

Packages usually link directly to their dependencies at compile time, except for scripting programming languages(which aren't expected to have linking functionality). Propagated inputs are used for the transitive dependencies you mention, but they should only be used for required dependencies that have to be installed with the package for it to detect them.

Packages shouldn't need to have symlinks in their output to another package when it could just directly reference it instead. More information on how native-inputs, inputs and propagated-inputs are different is explained in the Guix manual:
https://guix.gnu.org/manual/devel/en/html_node/package-Reference.html#index-inputs_002c-of-packages

Re: Direct symlink farm for transitive dependencies vs search paths

[amano.kenji]

But, aren't search paths slower than symlinks when there are many transitive dependencies?

What about interpreted scripts that have many transitive dependencies?

Are symlinks to transitive dependencies sometimes used in guix channel?

On Wednesday, September 18th, 2024 at 5:49 AM, Adam Faiz <adam.faiz@disroot.org> wrote:

> > Let's say that A depends on B, and B depends on C.
> > 
> > With search paths, A doesn't have symlinks to B, and B doesn't have symlinks to
> > C. Thus, disk space is saved.
> > 
> > However, adding search path patches to existing softwares is cumbersome, and a
> > long list of search paths results in inefficient searches.
> > 
> > Let's assume that B has symlinks to C, and A has symlinks to everything in B.
> > This means A has symlinks to symlinks in B. Transitive symlink is probably more
> > efficient than search path. If A just copies symlinks from B and has symlinks
> > to plain files in B, then A ends up with only direct symlinks. Direct symlinks
> > are more efficient than transitive symlinks.
> > 
> > It seems that search paths are preferred over symlinks to transitive
> > dependencies in gnu guix. Why?
> 
> Search paths are preferred because their purpose is to provide a list of places to look for extensions/plugins/mods of a package. Essentially, search paths are a way to provide runtime dependencies that are optional.
> 
> Packages usually link directly to their dependencies at compile time, except for scripting programming languages(which aren't expected to have linking functionality). Propagated inputs are used for the transitive dependencies you mention, but they should only be used for required dependencies that have to be installed with the package for it to detect them.
> 
> Packages shouldn't need to have symlinks in their output to another package when it could just directly reference it instead. More information on how native-inputs, inputs and propagated-inputs are different is explained in the Guix manual:
> https://guix.gnu.org/manual/devel/en/html_node/package-Reference.html#index-inputs_002c-of-packages

Direct symlink farm for transitive dependencies vs search paths

[amano.kenji]

Let's say that A depends on B, and B depends on C.

With search paths, A doesn't have symlinks to B, and B doesn't have symlinks to C. Thus, disk space is saved.

However, adding search path patches to existing softwares is cumbersome, and a long list of search paths results in inefficient searches.

Let's assume that B has symlinks to C, and A has symlinks to everything in B. This means A has symlinks to symlinks in B. Transitive symlink is probably more efficient than search path. If A just copies symlinks from B and has symlinks to plain files in B, then A ends up with only direct symlinks. Direct symlinks are more efficient than transitive symlinks.

It seems that search paths are preferred over symlinks to transitive dependencies in gnu guix. Why?