-
Notifications
You must be signed in to change notification settings - Fork 29
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
Introduce GHC.X.hackage proposal #27
Conversation
https://github.com/bgamari/tech-proposals/blob/ghc-x-hackage/proposals/001-ghc-x-hackage.md might be a rendered link |
Thanks for writing this up! The proposal envisions one overlay per major GHC version. But a major GHC version may not be the only case where a large scale migration needs to happen - if a library far down in the dependency tree (or up) changes in ways that need adjustments in many libraries, it seems we are in a similar situation. Could we have a hackage overlays for these as well? Thinking in the other direction: is having multiple overlays the right call? I see the advantage of not worrying about other GHC versions, and the implicit garbage collection, but there is also redundancy (likely the patch for GHC-9.14 is also needed for GHC-9.16). How would a single “compat patches overlay” repo fare? |
Sorry to be a petty bureaucrat but What's the process for submitting a HFTP? says
I don't see such a discussion on the Haskell Discourse. If I have missed it could you please link it? If not, could you please start the preliminary discussion there? |
I have started a discussion here. |
This proposal looks great. I'd be keen to help out once the ball gets rolling. I have a couple of questions/suggestions:
|
To update: we met today and we look on this favorably. As it appears active work on fleshing out implementation is being undertaken by the stability working group, we'll hold off on a formal approval until everything shapes up. |
In the (very long) discussion thread in haskell/core-libraries-committee#22 it came up that doing library impact assessments today is also difficult. I would like to see In particular, a proposed litmus test for pulling the plug and doing the |
@Bodigrim left a very nice description in ghc-proposals/ghc-proposals#287 (comment) how the Simplified Subsumption regression test was botched. That's a bummer, but also makes crystal clear how this proposal can help. When the way to do such a test is well documented/automated, and the baseline control is well-maintained (so unrelated failures don't ruin the results), doing such experiments will be much easier and more reliable. |
Hi! Since I'm the "HF resource" (devops engineer) who might work on this, I thought I'd check on status. I don't yet have a personal opinion one way or the other yet since I'm not really plugged in, but if everybody else has a consensus, maybe we could finish crossing the t's and dotting the i's. |
Hi Bryan, thank you. I suggest:
In this phase I'd suggest also writing personally to the maintainers of a few dozen key libraries (i.e. ones with many dependencies). Actually doing all this takes a bit of bandwidth, which we are always short of, but which your presence will help with a lot. It's as much about building consensus as about techincal content! All this is just my suggestion... the rest of the Stability Working Group may have other views. |
Indeed, this is a project which we hope to have you work on, @chreekat. |
I have attempted to use head.hackage in the past, and it didn't work for me. The specific problem I encountered was that a package I depended on had a policy of not releasing to real Hackage, only head.hackage, until a stable GHC was released. That package required a changed API to be compatible with the new GHC, so I was left with the choices:
All of those options were unpleasant. The specific package in question was very low down in the tree. I appreciate that head.hackage can parallelise updating dependencies, but uploading to Hackage must be serial. I think it is very important that head.hackage doesn't cause people to delay on uploading to Hackage, which it most definitely has in the past. |
As much as I want to reduce the churn around upgrading to a newer GHC, I'm afraid this proposal is a step in the wrong direction. It will waste lots of time by many people, potentially increase the fragmentation of the already fragmented Haskell community, and increase frustration in some areas (even if reducing it in others). I'm going to elaborate in detail on why I think so. Let's start with flaws in the described workflow:
This is not true. Maintainers A and B can submit fixes to package C instead of doing nothing. Both
We can help maintainers by simplifying Hackage upload workflow or providing necessary CI integrations (e.g. in form of documented CI workflows with examples). This is immediately helpful to everyone and will improve the situation straightaway without paying the high cost of this proposal.
The GHC.X.hackage proposal doesn't solve this problem. First of all, this is not a problem in Haskell at the moment since everyone can contribute patches upstream and packages can depend on specific commits. Secondly, if by saying that "the entire dependency tree of that package is blocked" the proposal authors mean "fixes are not on Hackage", the GHC.X.hackage proposal won't help here because it's, well, not Hackage either.
Having a more predictable GHC release schedule helps with that. If maintainers know that they need to wake up e.g. every February 18 to update to a newer GHC, they can sleep in peace for the rest of the year. Another proposal about tick-tock release cycle for GHC helps here better and moves in the right direction. So to me, it looks like the only feature GHC.X.hackage allows is the ability to write a single line in the package configuration — an alias of a bunch of patches — instead of enumerating all patches one by one. This is a nice benefit but I don't think it's worth the cost.
The main explanation of why the Haskell community has delayed GHC support (besides having breaking changes in GHC) is the fact that widely-used packages are maintained by single volunteers. And volunteers don't have to do what you want them to do, they'll do what they want and whenever they want. If a maintainer of a widely-used library disappeared from the Haskell community forever, then GHC.X.hackage made its way to perpetuity by having this patch and requiring everyone to always use GHC.X.hackage. Otherwise, GHC.X.hackage just asked lots of people to do lots of redundant work. In conclusion, I feel that this proposal tries to solve the problem of having scarce volunteering resources by requiring volunteers to do even more which obviously doesn't work. |
I was in the midst of writing my own comment, but @chshersh said everything I was going to say. (And said it better!) For what it's worth, I've never used head.hackage. When upgrading GHC, I've used the Git source feature of both Cabal ( |
(I have not read the proposal itself yet, so my thoughts here are entirely untainted with any idea of what we're talking about) Having just done a bit of work developing compatibility with GHC 9.4 for the It took about two days of labor to get The primary difficulty, IMO, is updating the strict version upper bounds. I wonder if there's a way to automate that process - ie, if After that, actually implementing the changes needed in The main advantage that a So, if Makes me think that the 'proper' fix is to have an index of Haskell packages that are known-to-not-build (either via constraints, |
I think there's a plethora of issues:
I think the main issue is figuring out build failures and having clear public visibility about those. This is something that should be part of hackage itself. And even point 2 could be argued to be part of hackage. This proposal somewhat fixes point 3, but I think that's not the biggest issue of all. head.hackage could simply just be a |
OK, reading the proposal and learning what
The workflow is a bit clunky. I'd really prefer to just say "Here's a GitHub pull request, please make the relevant patch stuff for me." I'm already going to be making a PR upstream with my fixes, might as well share the work here. One problem with integrating this into my workflow is that many packages I maintain are part of multi-package repositories. So a change to
Hm. Some packages re-export things from For the (ah, this is covered slightly further down in the doc)
This whole sections seems really dicey. I think the discussion is mostly correct - the system is too error-prone to be worth any investment of energy. I'm happy having a PR up that links to dependent PRs that require release before a Hackage version can be made, and providing a
I've repeated over-and-over again that we have a problem with upper bounds, and that is that we conflate "This is known-not-to-work" and "This is not-known-to-work." For a bound "This is not-known-to-work," we can always just test it and see if it works when the relevant version comes out. Then we either update it to "This is known-to-work" or "This is known-to-not-work." If Hackage had some support for automagically bumping upper bounds on GHC boot packages (eg The presence of hmmmmm 🤔My overall impression is that this is a lot more work than my current workflow. It'd be nice to share some of the work (I'm sure I'm not the only one to patch Really, I just want to be able to share |
With Stack, you can create and share a custom snapshot that includes a bunch of With Cabal, I don't think it's quite as nice. As @hasufell mentioned, you can cram all the same stuff in a For Cabal developers, head.hackage (and this proposal) provide a developer experience that's similar to Stack's. You just add a new repository to your Cabal configuration and you're good to go. That makes me wonder: Is it possible to make an ad hoc Hackage overlay from a I'm just thinking out loud here, so feel free to ignore all this. I mainly wanted to point out that you can already get something like GHC.X.hackage using a custom snapshot with Stack. |
No, they won't. The next cabal release will support include directives for These may also include resolver constraints, so it's much more ergonomic than using stack for this. |
Great! That was news to me, so I hunted down the pull request: haskell/cabal#7783 |
I want to echo this. Upgrading my company's codebase to GHC 9 was a not-difficult process, as I can just make forks to upstream repos and reference the new commits in extra-deps. I'd rather see updates to this issue: haskell/cabal#7821 |
It sounds like the main concern is duplicate work. Perhaps the process for "constructing" the head overlay can make use of people submitting pointers to patches automatically, so as to reduce duplication here? |
I'm not sure it is. As I pointed out I'm not convinced this solves the core issue, which is visibility of required work, overview of current patches and a communication platform. head.hackage seems to be somewhat specific to GHC workflow. What makes us think it will help engage less active maintainers? It only talks about the patching workflow. |
@david-christiansen I would extend the problem statement to also mention that |
Accordingly, this is why I am not really worried about what technical form the initial GHC.X.Hackage takes. To the extent it is hard to contribute to, regular users will use it without contributing back, but that is fine! Merely having more consumers of the thing will inspire a few people that don't mind the technical hurdles to work on it more anyways --- we can also argue it's firstly GHC team's responsibility to ensure GHC.X.Hackage is good enough so that upon release there is proof to the community that the new GHC is usuable / isn't too disruptive. If later the GHC team feels overburdened keeping the thing up to date themselves, and the community is clamoring to help out, then we can refine the technical details to make it more convenient, but for the initial step I'm quite happy to just worry about the social problem of |
Yes. I'm also leaning towards "just do it" without a proposal. A proper proposal that tries to put the pieces together can happen later. |
I personally wouldn't benefit from GHC.X.hackage explicitly (but I might implicitly, only time will show) as I won't be using this overlay by myself. Already existing workflow works well for me. I also like how I can easily see the libraries from my However, this proposal being the HF Tech Proposal, if accepted, may actually make my life more difficult (I can speak only for myself) by:
I always have this feeling in Haskell that people are eager to dive into complicated tech solutions just to avoid dealing with humans. Yes, dealing with humans is not easy but the entire Haskell ecosystem is built by those humans. It's not sustainable for the entire community if you find it easier to maintain an entire overlay of patches and implement various strategies for retiring patches just to avoid asking maintainers "How could we help you?" or simply understanding that people might disappear. I don't like derailing the conversations around the proposal by suggesting different solutions. But if the ultimate goal is to release new GHC versions faster, then a proposal like the below one helps to achieve the goal in a more community-friendly way: If I'm on my 2-week vacation and someone has a burning need to support new GHC in my library ASAP, I'd rather let them merge their patches directly to my project and release it to Hackage without my involvement at all instead of contributing patches to some external overlay because I'm not available. Addressing some specific details,
I feel like Stackage already does this and it's quite successful. I don't benefit from this process as it requires to use
This can be solved by having better and more visible documentation. Lots of Haskell developers simply don't know they can depend on specific commits of packages even though this feature is available for more than 6 years in the Haskell ecosystem!
The assumption here is that the maintainer of a package with lots of dependencies will wake up first and went on a crusade to fix upstream packages. But this is not always the case. I personally wait for at least several months before I even try to upgrade to a newer GHC. Usually, existing GHC works fine for me and I don't have an urgency to upgrade to it.
The same is true for GHC.X.hackage. Someone has to contribute a patch. It can be anyone who has free time and enough competency to do the patch. Not necessary the person who needs it. Describing a workflow for contributing patches upstream (e.g. in a form of a blog post but better official guides section) will help lots of people and will significantly decrease the threshold for being an active member of the Haskell community.
Having HF support for this proposal puts it into completely different perspective. For instance, one of the primary HF goals is to be the glue that connects the entire ecosystem. I don't feel this proposal supports this goal and, in fact, goes against it. Without the proposal and having official HF support - go for it, you have my blessing 👼🏻 I'm not in a position to tell volunteers what to do in their free time. If some people want to implement GHC.X.hackage and others want to use it -- good for them 👍🏻 As always, people can do whatever they want in their free time. If it doesn't hurt me and makes life easier for someone else -- I'm happy for them and it doesn't bother me at all 👏🏻 |
@chshersh Well, let's start with the purpose of this proposal, which is is simple: Foster a way for the community as a whole to collaborate on patched packages so GHC releases are maximally usable on day 1. How this is accomplished is completely secondary. If the means are too controversial I would advocate splitting the proposal so we can first agree on the goal and then decide on the means. Would that address your concerns?
Following what I said above, this proposal should instead be at getting us to start dealing with other humans more so we don't just suffer in isolation redundantly creating the same patched package workarounds. It should be pro human interaction! |
|
Thanks to @david-christiansen for summarizing the current state of the discussion. This is extremely useful. To reiterate a few of his points:
David's interpretation is precisely right. GHC.X.Hackage is intended as a means for managing the problem of slow maintainers, which arise for at least two reasons. First, there is time availiability: maintainers have lives, go on vacations, and have busy spells. Such is life and currently we have no good mechanism for managing this fact. The second reason is a bit trickier: some maintainers are (understandably) reluctant to merge patches updating their packages for a new GHC release until the release is final. Working around this fact was the original motivation for developing
Indeed this is why we use patch files: they are the least-common-denominator when it comes to representing changes to packages. That being said, I should note that the existing scripts for managing
It's true that the proposal doesn't attempt to solve the "work-list" problem. However, I would argue that this is an orthogonal problem and one that is to some extent already addressed by the Hackage matrix builder (although it seems that it's fallen into quite a state of disrepair, sadly). @chshersh says,
The Haskell Party Proposal is a nice proposal, but it doesn't address the same problem that we are attempting to address here. It requires that maintainers opt-in, which many maintainers will be understandably reluctant to do. This means that the serial nature of ecosystem evolution is essentially unchanged. |
Apologies for misinterpreting the main goal behind this proposal. I thought the main goal is to "allow maintainers to upload their libraries to Hackage with the full support of the latest GHC and all dependencies so not-so-advanced Haskell users can use them after the new GHC release as quickly as possible without the need to learn about Hackage overlays" (which, obviously, the GHC.X.Hackage proposal doesn't solve) and not "solve the serial nature of the ecosystem evolution" (which is not solved by the Haskell Party proposal, as you correctly noticed). In that case, maybe this goal can be highlighted better in the motivation section? E.g. a separate paragraph of bold text after a phrase like "The proposal solves the following problem: ...". Currently, it's too ambiguous in the "Motivation" section and can be misinterpreted as this GitHub thread shows. |
There really seems to be a misunderstanding about the motivation then. If the motivation is to have quicker adoption on hackage of new GHC releases, then the workflow problem (which is not addressed by hackage matrix at all) is far more important than patch gathering. To me it seems that this proposal is more focussed on GHC and less on ecosystem. In that case probably no one disagrees with the proposal, but it should be made clear then that it doesn't attempt to solve the larger ecosystem issues. |
I would love us to focus our scarce attention and resources on the most important problems first. For me, the motivation is
As it stands, the proposal is about de-serialising the workflow. But if there is an even more pressing issue around workflow, maybe someone can sketch out what the problem there is, and how we might address it? To be concrete, here is what I think you may be saying. We need a centralised way to see:
So a kind of public work-list. Is that what you mean? Or maybe something else. You know far more than I do about the issues here. |
Yeah, the way I would envision is it somewhat like this: MotivationThis proposal attempts to decrease the adoption time of new GHC releases in the community and make contributing patches to the ecosystem easier. Proposal requirements
Workflow sketch
ScopeThe scope is currently about adopting to newer GHC versions, but could be extended to all ecosystem adoption issues (compare with aeson-2.0 change). My personal opinion is that as much as possible of these solutions should be part of hackage itself. Ideally, there would be a way to simply upload patches on hackage, then a bot would submit a PR to the maintainers github repository (if any) or send it via email. Hackage would automatically update list of submitted patches, add references to the pull request and somehow monitor changes to the PR itself (if any). Those things would be nice to have and the underlying tools to achieve the workflow can easily be switched. Hence the proposal focuses on the workflow, not the tools. Not all of these things need to be solved at once. |
I'm not convinced that there is truly much of a difference between these two sets of requirements; I have personally found For what it's worth, I agree that your proposal would be useful and would solve another set of problems. However, it strikes me as quite ambitious. This is of course not a bad thing, but the GHC.X.hackage proposal was intended to be minimal in the sense that it takes something which we already have and which already addresses a clear purpose, and extends it to slightly widen that purpose, allowing more people to benefit from it. The investment needed to reap the benefits from GHC.X.hackage is quite small; however, if the consensus is that these benefits are also quite small then I'm happy to shelve the proposal. |
@bgamari apologies... l wasn't really criticizing the proposal on its own. Only the scope/motivation it describes. I think the proposal is an improvement and should be implemented. Versioning the overlays makes sense for various reasons. My idea would simply be to
I believe that the GHC.X.hackage proposal can simply be executed in parallel. We might then later agree that it's part of the workflow solution. And even if it's not, it may still serve a purpose for other use cases (such as GHC, bleeding edge CIs etc.). As such: I propose to narrow the scope of the proposal or be deliberately more vague about what problems it solves: e.g. "we want to version the head.hackage overlay to allow users to rely on them for different GHC version that are not yet fully supported on hackage, potentially facilitating a patch workflow that allows users to more easily contribute". |
The proposal doesn't seem to mention Non-maintainer uploads. There is clearly an overlap, and the proposal should discuss the differences and which option to pick when. |
I think that the revision to the proposal that @bgamari just pushed at least resolves some of the ambiguities, and hopefully in the process addresses some of the concerns expressed here. In particular, it clarifies that:
Thoughts? |
The revised proposal still doesn't mention NMUs. |
@phadej I specifically attempted to address this concern, which makes me think that I have misunderstood you! I interpret your concern as asking whether patches in the GHC.X.Hackage overlay can be uploaded by non-maintainers. The answer is "yes" - in fact, non-maintainers are expected to be the primary contributors of patches to GHC.X.Hackage. But, given your comment, I suspect that you in fact have a different concern related to NMUs. Can you expand upon it a bit? Thanks! |
@david-christiansen you did. I meant NMU procedure for Hackage (not GHC.X.Hackage): https://github.com/haskell-infra/hackage-trustees/blob/master/policy.md#3-source-changes-simple-patches |
Ah, OK, @gbaz explained to me what the concern is - sorry for being a bit dense! What do you think about the following:
|
Oh dear, it looks like @david-christiansen and I raced. I just pushed the following language to address NMUs:
@david-christiansen, do feel free to amend as you see fit. |
Sorry, I've been very out of the loop here, but I wanted to add a useful observation. We've been prototyping something like this for use inside IOHK, and we really wanted to be able to gracefully include patched versions of packages. What we realised is that PVP versions can have an arbitrary number of components, and it turns out that cabal deals perfectly well with these. So you can adopt a policy whereby a patched version of X-1.2.3 should be included as X-1.2.3.0.0.0.0.1, which has the desired properties of a) being very unlikely to clash with a genuine release and b) being strictly greater than the released version. I think this scheme can alleviate a lot of the worries about which version number to use. Just pick a scheme like "add four (or N) zeros and then start incrementing". |
I would want to add a further element here -- while GHC.X.hackage repos will too exist, I would hope there is a "sunset" (perhaps the release of the following ghc) where they stop accepting packages. In particular, we wish to encourage that these repos are used strictly for testing and compatibility work -- having a cutoff on accepting new patches would encourage that they not become long-term sources of truth for ongoing non-testing and non-compatibility development. |
I understand the motivation here but surely the sun can set only when all the packages with patches in GHC.X.Hackage have been updated in Hackage. And that timetable is in the hands of package authors. Perhapes it would help if GHC.X.Hackage was accompanied with some kind of status board showing which packages still needed updating in Hackage? Package authors might find that helpful because they could readily see when their dependencies are all up to date. If the sun sets (e.g. GHC.X..Hackage is withdrawn for version X) before all packages have been updated then that version X of GHC will abruptly become unavaialble to clients who are depending on those patches. That would not be a good look. |
I understood what @gbaz said as stop accepting new patches, not that the repository itself would go offline. |
Ah, I did not understand that. If it goes into the proposal, let's make that clear. But still, it would mean that a user U would be unable to use GHC.X.Hackage to patch an obscure package P, whose maintainer was absent. Thus GHC version X would be permanently out of reach to U, which again seems undesirable. |
Oleg's interpretation is correct. But this would not mean that X would be out of reach to U. They could simply fork U and use a cabal.project or the like to point to the repo. It would mean that GHC.X.Hackage would not be a place to continue to perform "testing and compatibility work" for GHC version X. However, this "sunset" would occur only after GHC version X+1 was released, at which point that is where future testing and compatibility would make sense to be directed to. I believe such a sunset would nudge users to treat GHC.X.Hackage as a testing and compatibility area, and not as a permanent source of truth in a way that has relatively minor costs -- i.e. those most affected would only be those who were tempted to use it for unintended purposes to begin with. Further it relieves the GHC.X.Hackage maintainers of the burden of having to accept and review patches for all past GHCs indefinitely. By the way, I believe the negative concerns expressed in section 6.3 on "precognitive releases" are too negative. Consider if P depends on Q at version 1.1.0 and that fails to work on GHC X, but is patched in GHC.X.Hackage. I claim that releasing a P that depends on some Q 1.1.x (i.e. with pvp upper bounds) remains safe. In the best case, Q 1.1.1 is released promptly, provides compatibility with X, and all is good. If no such Q is ever released, then P's bounds remain correct, and P just remains unbuildable with GHC X. If a Q is later released that is compatible, but it is Q version 2, then if P still builds with it, then only a bounds revision need be performed -- no new release. Only in the case that if Q is released at 2, and P does not work with it, a new version need be released that updates to be compatible with Q -- and the total cost of having made one incremental release is relatively minor, and has done no harm. |
It seems that the community is generally somewhat lukewarm with respect to GHC.X.Hackage. Based on this feedback, and rather than going through the formal vote process, we're now planning on just doing a little trial to get some experience: we'll do one iteration of GHC.X.Hackage (perhaps GHC.9.6.Hackage), see how it works in practice, and evaluate it based on the reception. If it's a runaway success, great! If there is not widespread adoption, then we'll be in a position to figure out whether the lack of adoption is technical (and can be fixed) or if the solution just doesn't match community needs. Thank you again for your feedback! |
For a few years now the GHC team has maintained
head.hackage
a set of patches to a subset of Hackage allowing Hackage packages to be built against pre-release compilers. Whilehead.hackage
has been an invaluable resource for testing GHC, its user-base has been limited to GHC developers.In the past few months, there have been a few proposals seeking to lower the cost of migrations to new GHC releases. A common theme in these discussions has been the long lead-time for adoption of new releases due to the largely serial nature of library migration. We propose to extend
head.hackage
as a tool to help users migrate and test their libraries.Rendered version