NixOS/nix

Collect "file system object" parts of `libnixutil` together

Open

#9.278 geöffnet am 2. Nov. 2023

Auf GitHub ansehen
 (6 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C++ (1.293 Forks)batch import
good first issueidea approved

Repository-Metriken

Stars
 (9.803 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 4T 12h) (86 gemergte PRs in 30 T)

Beschreibung

We now have bunch of involved code for working with file system objects.

Someday it might be good to codify this into a new libnixfile. (Don't worry, that doesn't mean I am planning a "file-only" Nix!) But going down that road would mean lots of little libraries, which could have implications for dynamic linking. For now we can instead group files into subdirectories (see build/ in libstore for this same concept), but keep all such directories linked together in the parent library.

For initial contents I am thinking:

  • src/libutil/archive
  • src/libutil/canon-path
  • src/libutil/fs-sink
  • src/libutil/git.cc will contain more stuff after #8918
  • src/libutil/posix-source-accessor
  • src/libutil/source-accessor
  • src/libutil/file-content-address New, doesn't distinguish between "flat" and "text" because w.r.t file system objects (as opposed to store objects) they are the same.

I think this will continue growing too based on our current plans. libnixfetchers only barely depends on the store layer anyways, so I think some or even all of it could end up here too.

Contributor Guide