Please help with removing hnix-store-core

[Anton-Latukha]

Good day.

I am the currently active Haskell-Nix group maintainer, and hnix-store-* maintainer.

The hnix-store-core was published, one time, to the stackage, date is: 2020-03-12, almost a year ago.
Then after the publish, in 11 months, there was no proactive maintenance by the publisher of it in the stackage.

Because nobody holds LTS obligations on maintaining hnix-store-core, and the project being on stackage complicates our downstream processes for hnix-store-core, hnix-store-remote & hnix if you can, please free hnix-store-core from the enlistment in LTS obligations. It would help me tremendeously.

[bergmark]

Hi @Anton-Latukha,

Maintainers are always free to remove their package from nightly, preferably by removing it from build-constraints.yaml in this repo. That will also prevent it from being included in the next LTS major release. We've never had a request to remove a package from LTS before (I think) so I'm not sure what to do here (I'll ping the other curators). But i'd like to make it clear that we do not expect you to support an old version of a package, you can simply ignore any issues related to LTS. If hnix-store-core remains in LTS until we do next major LTS release, would that be ok for you? (that's less work for us).

But because of #5766 we will at some point close that issue and remove hnix-store-core anyway. So perhaps we should just do that immediately :-) @juhp would you mind?

[Anton-Latukha]

Hi @Anton-Latukha,

Maintainers are always free to remove their package from nightly, preferably by removing it from build-constraints.yaml in this repo. That will also prevent it from being included in the next LTS major release. We've never had a request to remove a package from LTS before (I think) so I'm not sure what to do here (I'll ping the other curators). But i'd like to make it clear that we do not expect you to support an old version of a package, you can simply ignore any issues related to LTS. If hnix-store-core remains in LTS until we do next major LTS release, would that be ok for you? (that's less work for us).

But because of #5766 we will at some point close that issue and remove hnix-store-core anyway. So perhaps we should just do that immediately :-) @juhp would you mind?

No rush.

Just cranking down the situation.

hnix-store-core was in a rough state for some time. And it being on stackage without hnix & hnix-store-remote... Because of Nixpkgs connection, we need to be or on Hackage only, or on Stackage fully, because if anything of hnix* stays in between - we (& Nixpkgs maintainers) have a hassle in Nixpkgs. Nixpkgs "Default" haskellPackages.hnix-store-core, is Stackage's recommended version 0.2.0 which is seen in package listing, so for Nixpkgs we need to ship an "official package/unoficcial side-package", by the Nixpkgs process & policy it can have only naming haskellPackages.hnix-store-core_0_4_1_0, where package name hardcodes the version. So every release we (being proper maintainers) need to go to Nixpkgs and override everything that used haskellPackages.hnix-store-core_0_4_1_0 to new haskellPackages.hnix-store-core_0_x_x_x, that also involves quite complex time window management to do it roughly properly, and during that Nixpkgs maintainers are supporting us.

[bergmark]

Ah that clarifies things a lot for me :-) I did not consider the stackage/nix interaction

[shlevy]

@Anton-Latukha Sorry, I didn't know you wanted anyone besides @sorki added. Happy to include whoever you think is appropriate.

[shlevy]

Also, this is not a big deal, but FWIW I don't think it's fair to say I was unresponsive. I let people know I wasn't actively working on these any more and handed over appropriate access to those who had been keeping up the work within a reasonable time from when asked.

[Anton-Latukha]

@shlevy

Well, understand, happens.

After all you created the project and moved it close to a finish line, so it is understandable that one gets tired.

Specifically not used personnel from the process description. Until it would've been strange that the person that has only repository access raises the question of removing the project package from Stackage LTS, so enumerated the known accesses of called people.

Happy to include whoever you think is appropriate.

Any set of people that would be proactively indeed holding responsibility. Great when maintainers participate in the project processes. At least constantly once a week. Great when one does not need to seek & request from maintainers to maintain the project and to ask maintainers to make releases and if platform support fixes are needed - to provide them before others noticed, when being the maintainer is to know that fixes and releases are needed to be made because it simplifies the life of others, the release processes, and the downstream flow at the same time.

We had a tight circle this year, if it is not being me - then @layus. But the release team discussions belong to the hnix-store repo.

Worked quite a bit this year (mainly in hnix) to ramp-up the processes and to give the quality of life in the projects and allow some onboarding, hoping that when some milestone would be achieved (this year or next year), the community would expand somewhat.

But the hnix & hnix-store-remote being Hackage, and hnix-store-core being Stackage LTS, and not being maintained there, all that tied together by the Nixpkgs - seems strange at least, if not to say quite inconvenient to keep working.

[Anton-Latukha]

It all started very simple. Currently hnix-store-core does not builds for macOS for an unknown number of time (because there was no CI, so no build history). Somewhere up to 11 ago, or since macOS does not have /proc (do not know if ever had).

macOS build fail was caught in hnix, but it was a build fail of hnix-store-core, so transferred report there haskell-nix/hnix-store#109 and went to deploy the CI macOS build there haskell-nix/hnix-store#114 to solve it further upfront. And after that (for 1.5 months) nothing, meaning "Anton, do everything yourself".

The question to fix it - is to automatically set one flag to remove the /proc-related test on macOS.

But I do not want, as lately frequently, instead of the official maintainers to care about it for them. Making the flag is simple. And then call and beg maintainers to show-up & review merge the fix to merge it, because they do not show-up, it is a self-merge, well ok... Then beg the official maintainers to release the project...

After the release then I personally go and fix in Nixpkgs all the things related, because Stackage LTS package not being maintained by maintainers.

That is quite a lot of hassle to provide 1 binary flag to support the platform I do not have. I need somehow to carefully flop over quite a lot of people who not being maintainers, to pass through them the maintenance of the project.

That is to submit 1 binary flag that project interest in the first place. That is a bit too much human gymnastics overhead for me to include a bit flag, when people assigned and self-picked in the chain should be solving it beforehand.

So that is why started with Stackage, traversing the pipeline.

---

Overall, this year as said, personally plan a reorganization of hnix (preparation and split of it into 4 packages, Expressions (language & parser), Evaluation, Executable (CLI), Extra (Lint, Convert, Format & so on). And soon plan refactor hnix-store-core hash interface and do needed work there. With hnix being 4 packages and store being 2, it, also because of lacking maintainers, seems logical to form 1 monorepo, so all projects get maintained by 1 team.

[sorki]

I'm not unresponsive either, just a little demotivated by you constantly neglecting opinion of other maintainers.

With hnix being 4 packages and store being 2, it, also because of lacking maintainers, seems logical to form 1 monorepo, so all projects get maintained by 1 team.

haskell-nix/hnix#328 (comment)

Regarding store itself, because of cryptohash-sha512 breakage you considered our release broken and kept ranting about the poor job we did and how we dare to release something sub-par that doesn't even build on Hackage.

Recent break-other-maintainers-workflow as it doesn't work with your HLS or whatnot doesn't help with my motivation either.

[Anton-Latukha]

@shlevy, @sorki. I love you.

hnix-store-core is not maintained on Stackage LTS for the 11 months. That creates problems for the last half of the year. For Nixpkgs, their maintainers and for hnix and for others. How it would solve further after?

[sorki]

Sorry for being off-topic - I'm fine with dropping this from stackage for now and also giving you Hackage access.

[Anton-Latukha]

We have a very small team, it means we have a small resource of effort, and there is a huge volume of things to do, models of preserved effort with enough output quality seem great to use in this situation.

Please, between releases we always can fix everything by simply paving over proper fixes by own hands, lets allow one another some room for contributing documentation, minor clean-up refactoring, and fixes to the needed things. We need to cross-review really only the functionality changes, and be sure that everything in the project is proper for release.

[juhp]

If you still really want us to consider bumping the version in LTS 17, then please open a separate lts-haskell issue, thank you.

https://packdeps.haskellers.com/reverse/hnix-store-core

I have dropped the upper-bound now for Nightly: though there various problems in Nightly right now, so I am not sure when the next one will be published, but hopefully soon.

[Anton-Latukha]

@juhp

https://packdeps.haskellers.com/reverse/hnix-store-core
The hnix-store-core hnix-store-remote and hnix are our mutual projects. Stack currently is not used in them. Presents of 1 of 3 on stackage - complicates our downstream support in Nixpkgs for all of them, because Nixpkgs inherits from Stackage first, than from Hackage. Because of that Haskell infrastructure Nixpkgs coupling downstream, and of the Nix derivation management, hnix-store-core hnix-store-remote and hnix need all to be or on Stackage, or just be on Hackage.

And 3 projects are not ready for Stackage. For example: https://github.com/haskell-nix/hnix/blob/master/ChangeLog.md, projects are still in the phases of moving things around to organize and stabilize the API, projects have not arrived at MVP. For example, only when the hnix interpreter would be able to produce effects together with hnix-store-core and when interpreter & store would manage nix derivation operations - testing of "does package manager and the store projects able to do a basic I/O roundtrip" that would be some MVP state.

Maintainers&creators of hnix-store-core hnix-store-remote and hnix participated in the thread and ok to remove the package.

The fourth reverse dependency: https://git.sr.ht/~jack/nix-freeze-tree/tree - does not have stack configuration.

So hnix-store-core is not used from Stackage by any reverse dependency. That is why requesting to remove it. Moreover, the publication is in rough shape.

Removing the upper bound just prolongs the situation for some time.

Thanks, everybody.

[juhp]

Thanks for the clarifications - I have blocked the package now.

If you need action for LTS please open a separate issue for that as mentioned.

[Anton-Latukha]

Thank you.

Of course, let it happen properly and gracefully.

I myself hope projects would reach MVP and reorganize, when things would start to move to us, then we would be able go to the stackage, as we would have the team large and active enough to maintain the packages properly for you.

Thank you.

[Anton-Latukha]

And to finish: in this thread, I was guilty of interpreting some details of our team processes wrong, to which team members had reactions. I apologize, still learning.