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.

Sign up for GitHub

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

Jump to bottom

Support hnix-store packages >= 0.5 #952

Closed
expipiplus1 opened this issue Jun 14, 2021 · 5 comments
Closed

Support hnix-store packages >= 0.5 #952

expipiplus1 opened this issue Jun 14, 2021 · 5 comments

Comments

@expipiplus1
Copy link
Collaborator

Looks like some functions have changed name and location.

Currently breaking in nixpkgs where only the latest hnix-store (and -remote) are available: NixOS/nixpkgs#126693

@Anton-Latukha you seem to be behind the changes in hnix-store? Are you able to tackle this?
@expipiplus1 expipiplus1 mentioned this issue Jun 14, 2021
Merged
@sternenseemann
Copy link

If this is gonna take longer, downgrading the hnix-store packages in nixpkgs may also be a valid course of action.

@expipiplus1
Copy link
Collaborator Author

Indeed, hnix is the only non-broken package depending on them.

@Anton-Latukha
Copy link
Collaborator

Anton-Latukha commented Jun 14, 2021 •
edited
Loading

Yes, I did {Core,Remote} changes & release, & guilty to forget to check Nixpkgs & submit a patch there.

Logically it is if one kinda needs an interpreter to work between the Nix store & the Nix configuration. Due to that {Core,Remote} are currently essentially an internal projects, they would get a lot more own traction transitively when HNix lib would work & be popular people would come over & if they would find they do not need HNix lib - they would use Store directly. Currently is Ok to freeze versions there: since https://packdeps.haskellers.com/reverse/hnix-store-core.

There is no problem supporting those changes in HNix, the culprit to make a release is #858, it is the last one to give GHC 9.0 downstream, & GHC 9.0 support is why I made {Core,Remote} migration breakages & releases in the first place.

sternenseemann added a commit to sternenseemann/nixpkgs that referenced this issue Jun 14, 2021
@sternenseemann
haskellPackages.hnix-store-{core,remote}: downgrade to < 0.5
d49e15e 
hnix 0.13.* doesn't support hnix-store-* >= 0.5 yet, pending some
refactors to get GHC 9.0.x support working. Until that happens,
we downgrade hnix-store-* since nothing needs the new version yet.

haskell-nix/hnix#952
@sternenseemann sternenseemann mentioned this issue Jun 14, 2021
Merged
11 tasks
@sternenseemann
Copy link

sternenseemann commented Jun 14, 2021 •
edited
Loading

NixOS/nixpkgs#126840

@Anton-Latukha
Copy link
Collaborator

Anton-Latukha commented Jul 8, 2021 •
edited
Loading

This is done.

& I am contributing a Nixpkgs patch to unblock upstream packages.

sternenseemann pushed a commit to Anton-Latukha/nixpkgs that referenced this issue Jul 18, 2021
@Anton-Latukha @sternenseemann
haskellPackages: allow hnix-store-{core,remote} 0.5
fca4c19 
These were blocked due to mutual desigion during me<>`sternenseemann`
discussion.
haskell-nix/hnix#952

In short:

I shipped my own work (to support GHC 9.0) in the 0.5 releases of
`hnix-store-{core,remote}`.

These packages are really used only by `hnix` itself, and instead of maintaining
them in Nixpkgs & reacting on `hnix` release, we decided to hold them back &
switch to these versions when `hnix` provides support for them.

I just (today) released `hnix` 0.14 & it requires `hnix-store-{core,remote}`
0.5.

If you would look at dependency tree:
https://packdeps.haskellers.com/reverse/hnix-store-core
https://packdeps.haskellers.com/reverse/hnix-store-remote

It shows that `hnix` currently is the only alive use of these projects.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@expipiplus1 @sternenseemann @Anton-Latukha