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

Switch Derivation in Nix.Effects.Derivation to use nix-derivation package #1098

Open
sorki opened this issue Nov 18, 2023 · 7 comments
Open

Comments

@sorki
Copy link
Member

sorki commented Nov 18, 2023

The type should wrap nix-derivation Derivation and extend it with

  • name :: Text
  • mFixed :: Maybe Store.SomeNamedDigest
  • hashMode :: HashMode
  • useJson :: Bool

fields. Could be called e.g. HnixDerivation.

@Ericson2314
Copy link
Member

I sort of think nix-derivation perhaps should just be merged into hnix-store-core. Maybe this is a good thing to talk to @Gabriella439 about.

@sorki
Copy link
Member Author

sorki commented Nov 18, 2023

Well I have commit bit for nix-derivation (but not on Hackage) so I don't really care where it lives - I kind-of like our distributed nature TBH 😺

@Ericson2314
Copy link
Member

Yeah I guess same repo (for cross-cutting refactors) is more important than same library for me. I would definitely want to give @Gabriella439 commit bit to the hnix-store repo in exchange for eating her library if we do do this, that way there is no loss in number of cooks in the kitchen!

@Gabriella439
Copy link

My only concern is the dependency footprint of hnix-store-core (in particular, saltine, which has a dependency on a C library)

@sorki
Copy link
Member Author

sorki commented Nov 18, 2023

My only concern is the dependency footprint of hnix-store-core (in particular, saltine, which has a dependency on a C library)

I would keep it as a separate package provided it is pretty much done and self-contained so it won't suffer from this - also @Ericson2314 also means it like that I think - to make it easier to do cross-repository (edit: cross-library in single repository) refactors.

Tomorrow I want to split -core into two more librariers -nar and -readonly to have -core contain mostly core types and to make dependencies easier to manage (haskell-nix/hnix-store#233 & haskell-nix/hnix-store#235)

@sorki
Copy link
Member Author

sorki commented Nov 18, 2023

provided it is pretty much done and self-contained

Maybe except for the differentiation of BaseDerivation and Derivation which differ in just a single field we need to ignore in remote store protocol but that's not a big deal and maybe not even worth having a separate type

@Gabriella439
Copy link

as far as ownership goes i'm happy to transfer ownership / grant commit bits / relocate the repository as desired

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants