NixOS/nix

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

Open

#9,278 建立於 2023年11月2日

在 GitHub 查看
 (6 留言) (0 反應) (0 負責人)C++ (9,803 star) (1,293 fork)batch import
good first issueidea approved

描述

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.

貢獻者指南

技術棧
cpp
領域
developer experiencetooling
議題類型
refactor
難度面向新貢獻者的預計實作難度，1 表示很小改動，5 表示專家級工作。
3
預計時間有經驗貢獻者完成調查、實作、測試並準備 pull request 的粗略時間範圍。
1-2 days
活動狀態議題目前的可參與程度：新鮮、活躍、陳舊、阻塞或等待維護者輸入。
active
清晰度議題是否清楚說明預期改動、驗收標準和下一步。
clear
前置要求
basic C++ knowledgeunderstanding of Nix codebase structure
新手友善度1-100 的估計分數，表示該議題對首次貢獻者的友善程度。
40
研究方向
The issue proposes grouping file system object related code in libutil into subdirectories. First, explore the current files listed: src/libutil/archive, src/libutil/canon path, src/libutil/fs sink, src/libutil/git.cc, src/libutil/posix source accessor, src/libutil/source accessor, and consider where to place new code like file content address. Review existing subdirectory patterns in libstore (e.g., build/). Then create a plan to move and organize these files, ensuring includes and build system (Makefile or CMake) are updated accordingly. Check for dependencies between these components to ensure no breakage.