Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collect "file system object" parts of libnixutil together #9278

Open
Ericson2314 opened this issue Nov 2, 2023 · 6 comments
Open

Collect "file system object" parts of libnixutil together #9278

Ericson2314 opened this issue Nov 2, 2023 · 6 comments
Labels
good first issue Quick win for first-time contributors idea approved The given proposal has been discussed and approved by the Nix team. An implementation is welcome.

Comments

@Ericson2314
Copy link
Member

Ericson2314 commented Nov 2, 2023

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 Git object hashing in libstore #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.

@Ericson2314
Copy link
Member Author

@edolstra Are you OK with this? Part of my motivation is in #8918 many duplicative call sites need to be updated. I would to provide some new functions that abstract over those patterns (and work with arbitrary accessors) instead.

@Ericson2314
Copy link
Member Author

2023-11-17 Nix team meeting notes:

  • @edolstra: nope
  • @edolstra: I don't care about libnixfile, but we could start organising libutil a bit more (moving stuff to subfolders)
    • @Ericson2314: I like that. I'll do that first
    • I'll rewrite issue

@Ericson2314 Ericson2314 changed the title Move some parts of libnixutil into a new libnixfile Collect "file system object" parts of libnixutil together Nov 19, 2023
@Ericson2314
Copy link
Member Author

@edolstra if the main files go in a directory, and the main files are next to he headers, should we do more -I flags or should we do e.g. #include "file/canon-path.hh?

@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-11-17-nix-team-meeting-minutes-104/35753/1

@Ericson2314 Ericson2314 added the idea approved The given proposal has been discussed and approved by the Nix team. An implementation is welcome. label Dec 6, 2023
@Ericson2314
Copy link
Member Author

(Now that I did the requested reword of the issue, I think it is safe to say this issue is team-approved)

@Ericson2314 Ericson2314 added the good first issue Quick win for first-time contributors label Dec 6, 2023
@oxcabe
Copy link

oxcabe commented May 6, 2024

Hi, I want to work on this.

Someday it might be good to codify this into a new libnixfile.

So, the main thing here is that we have to move filesystem-related functionality from libnixutil to a new libnixfile lib, right?

But going down that road would mean lots of little libraries, which could have implications for dynamic linking.

Being a Nix-specific library, does it need to be dynamic, or could we just statically link it to the rest of the modules that depend on it? I infer it's way more convoluted than my current understanding of things.

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.

Inside libnixutil you mean, right? So we end up with something like src/libutil/fs/...

At any rate, we need to choose which approach to follow before refactoring. Also, please let me know if I got the idea correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Quick win for first-time contributors idea approved The given proposal has been discussed and approved by the Nix team. An implementation is welcome.
Projects
None yet
Development

No branches or pull requests

3 participants