add installer-guidelines proposal #7
Conversation
|
|
||
| * To provide a prototype Windows installer for cabal-install-based Haskell development | ||
| environments based on the stack codebase. This is the coverage we are missing at the moment and | ||
| it is easy to do. We anticipate it becoming quickly obsoleted as the more stablished installers |
There was a problem hiding this comment.
Tiniest spelling nitpick : established
|
Love this proposal! |
There was a problem hiding this comment.
I think overall, I'm not satisfied with this proposal. Here are the reasons:
- It dabbles too much in political shenanigans, claiming to solve disharmony or unify the community... those are all great ideas, but totally out of scope. Let's be pragmatic. We want to have a tool that works across all major 3 platforms. The main focus is to improve windows support and not discriminate certain build-tools. That's all. It's done.
- It mentions specific installers. It shouldn't. It should be totally agnostic of it and not care who or what satisfies these requirements.
- It doesn't really describe UX, except with terms such as "easy". I think we should either completely refrain from describing UX and just have hard requirements (such as platform support and non-admin install) or be more verbose in describing what we expect of UX and then accept the fact that some tools might not fit that description.
- The proposal should not contain any "may be extended in the future". If someone wants to add something, they'll have to create another proposal and discuss it.
- The proposal should make clear boundaries that signal to tool maintainers that they're ultimately in control of their project, UX and that their primary concern should be their users. The proposal should really just be guidelines, not hard criteria.
And last... it should make clear what the tool maintainers gain by following these guidelines.
| ## 0. Objectives | ||
|
|
||
| We want people to use Haskell, which means the path to installing Haskell for first-time users | ||
| should be short and easy, and it should yield an environment that is easy to use with the supporting |
There was a problem hiding this comment.
What is easy? For which type of user?
There has already been strong disagreements on whether "interactive" is considered easy or not.
There was a problem hiding this comment.
I think this needs to be left as an issue for the collective judgement of users. My strong suspicion is that there's a use case for both interactive and non-interactive installation, and that an ideal install tool would provide both options while installing the same a well-known and standardized environment regardless of the choice of UX.
There was a problem hiding this comment.
Yeah, ghcup does this today. But I think it's not useful to have such fine-grained technical requirements. It sounds like forcing ideas and requirements on projects through a formal proposal, instead of opening issues on the respective issue trackers, which HF has never done.
In general, I dislike the tone of this proposal. Maintainers don't work for the HF (at least I don't), they work for the community. And that community can already reach out to them and get their ideas and needs discussed.
So what do we need this proposal really for?
| and painless as possible. | ||
|
|
||
| These guidelines will set out the criteria that the Haskell Foundation will use in evaluating | ||
| installers. We do not expect any individual to meet all these criteria initially but we would like |
There was a problem hiding this comment.
What does the Haskell Foundation provide for developers of said tool. As in: what's the incentive to meet these criteria?
|
|
||
| As many platforms should be covered by the installers as possible. For now, the minimum platforms | ||
| that should be covered should include 64-bit Windows, macOS and Linux running on | ||
| Intel-x86-compatible processors. This set of minimal platforms will soon have to be extended to |
There was a problem hiding this comment.
It should include ARM now. GHC supports it, there's no excuse.
| * It should be possible to install and manage multiple toolchains that both `stack` and | ||
| `cabal-install` can use. This requires that both `stack` and `cabal-install` need to be | ||
| configurable to access a GHC toolchain that has been installed by the other and the installer | ||
| must configure both toolchains to work with the `starter` GHC toolchain. |
There was a problem hiding this comment.
This doesn't make much sense, because you can tell both stack and cabal which GHC to pick.
I feel that something else here is meant though and I believe it has no place in this proposal. This is an optimization/configuration concern.
|
|
||
| ## 3. User Installable | ||
|
|
||
| It should be possible to install Haskell in the user environment without recourse to administrator |
There was a problem hiding this comment.
Does this disallow invoking sudo from bootstrap scripts to install system dependencies? Because that isn't really "user installable".
|
|
||
| * Both of the principal build systems (`cabal-install` and `stack`) should be installed, | ||
| available and ready for use in the way their associated development communities would expect. | ||
| (If an installer interrogates the user on installation about which components to install it is |
There was a problem hiding this comment.
This is overly specific. Let the tool maintainers decide what reasonable defaults are.
There was a problem hiding this comment.
I disagree here. It's sufficiently important to make both tools available as part of the standard Haskell environment that any tool linked to by the community as a general-purpose installer for Haskell should be installing both by default. I'd add, though, that they should also be putting ghc and ghci in the path to be run directly, since that is also an important part of a standard Haskell environment.
This language still allows for tools to provide detailed options or customization. It just says that if you install "Haskell", that includes working cabal and stack executables.
There was a problem hiding this comment.
Since stack doesn't integrate well with standalone installers yet and has a self-update mechanism that can break your installer, I consider this feature experimental in ghcup and default installation of stack doesn't make sense yet.
| could easily download and run a installer to provide a standard Haskell environment that supports | ||
| the principal build tools (`cabal-install` and `stack`) on the main platforms (Linux, macOS and | ||
| Windows). All Haskell introductory material (text books, blog posts, etc.) should be able to point | ||
| to the Haskell Foundation download page and work on the assumption that it will yield their |
There was a problem hiding this comment.
Will this be a separate resource to https://www.haskell.org/downloads/ ?
There was a problem hiding this comment.
I hope not! It's clear to me that haskell.org should remain the contact point for getting started with Haskell. It's where beginners will look, after all, whether they are told to or not.
There was a problem hiding this comment.
It had been communicated to me that there very well might be a separate resource if haskell.org doesn't "comply". How much of that was really true, I don't know.
I personally hope that HF creates their own download page and that haskell.org stays independent. But that's just my opinion.
|
|
||
| To this end this proposal covers two things: | ||
|
|
||
| * To publish a set of minimal requirements for a Haskell installer that we are prepared to |
There was a problem hiding this comment.
I agree, the requirements should be minimal and I think we need to work on that.
| environments but we would like to move in that direction, for example.) | ||
|
|
||
| * To provide a prototype Windows installer for cabal-install-based Haskell development | ||
| environments based on the stack codebase. This is the coverage we are missing at the moment and |
There was a problem hiding this comment.
Strong -1
The proposal should not mention any existing installer tools or provide implementation bias. It should be neutral and not care who or what satisfies these requirements.
There has been far too much political play in the development of this proposal and we need to remove all of that from it.
| The exact configuration of Haskell development environments has recently been a contentious issue | ||
| leading to regrettable fragmentation and confusion. It should be a priority of the Haskell | ||
| Foundation to lead the way in restoring harmony for the health of the Haskell community and its | ||
| ecosystem. The Haskell Foundation should also be well placed to do this with its broad | ||
| representation at board level and many sponsors and friends in the community. |
There was a problem hiding this comment.
Strong -1
This is very opinionated. Fragmentation happens for various reasons. Some of them may be good reasons. This proposal should solely focus on improving windows haskell user experience and not start debates about cabal vs stack or make attempts to explain why confusion exists.
It is clear that windows support needs work and more options on windows are welcome. That's all we need to do here.
There was a problem hiding this comment.
I strongly disagree with you here. The path may be longer than I'd like to get there amicably, but having competing installers to get started with Haskell is clearly a bad user experience, and frankly sort of an embarrassing state of affairs. I'd love for people to agree on a set of standards mainly so that we can get to the point where one installer can meet those standards and become the clear choice.
There was a problem hiding this comment.
but having competing installers to get started with Haskell is clearly a bad user experience
Is it though? Competition in open source is natural. A "getting started" guide doesn't have to expose the user to all choices. I've said that numerous times.
I'd love for people to agree on a set of standards mainly so that we can get to the point where one installer can meet those standards and become the clear choice.
This is clearly out of scope of this PR (unification at least).
And I believe the HF has a lot of work to do before it should consider driving forward or moderating such an effort.
There was a problem hiding this comment.
This is why it's clear to me that all sorts of concerns are mixed up and mushed into one project:
- Downloads page
- UX for haskell newcomers
- Installer that works across all platforms
- Smooth integration of standalone installers with stack
- Unification of tools or implementations
All of these are connected, but different things and need their own consideration.
There was a problem hiding this comment.
There's a clear story that connects the points you mention. 2, 3, and 4 are requirements. The downloads page is involved because it's the motivation behind the requirements: anyone is free to create any half-functional Haskell installer they like as a personal project, but if they want it linked from the Haskell downloads page, then it should meet community standards.
Unification is, indeed, not part of this proposal. We can disagree on whether that's a mistake, but in any case setting a high standard for all tools is a step toward eventual unification. My understanding is that stack maintains installer tools not because they want to, but because they saw certain needs that weren't met by general Haskell install tools (for one: Windows installs, and installing stack in the first place, which are now resolved; but also: allowing installs of GHC to be triggered by the stack build tool.) If these needs were met by a tool like ghcup, maybe we could get out of this embarrassing situation in the first place and have a clean story for how to install Haskell. I definitely look forward to this happening, and see this proposal as a stepping stone to get there even though this proposal doesn't ask for unification.
I cannot think of any other major programming language whose install page says "here are several competing ways to install". That's the embarrassing situation we're in here. When we tell someone how to install Haskell, there ought to be an answer of record to that question. Note that this doesn't mean there can't be other options, such as installing from an Ubuntu PPR, or Chocolatey for Windows, or some custom setup script if Haskell is bundled into a special-use project as I already do with CodeWorld. And if someone creates a better general-purpose install tool, that answer of record can change. But right now we're paralyzing newcomers with a choice they shouldn't have to make.
There was a problem hiding this comment.
There's a clear story that connects the points you mention. 2, 3, and 4 are requirements.
2 isn't really specified properly in this proposal. 3 has been done since ~2 months. 4 is WIP, awaiting approval/comments from stack developers.
The downloads page is involved because it's the motivation behind the requirements: anyone is free to create any half-functional Haskell installer they like as a personal project, but if they want it linked from the Haskell downloads page, then it should meet community standards.
And it's unclear what "downloads page" that is.
I definitely look forward to this happening, and see this proposal as a stepping stone to get there even though this proposal doesn't ask for unification.
So far, HFs involvement in these matters have caused more damage and disconnection than there was before. So again: I'm not sure HF is the right place to drive forward the unification vision. The maintainers of the tools have to find a point of minimal consensus and work towards something. This is probably not the right time to think about it.
Unification is less a technical challenge than it is a collaboration challenge. Stack maintainers need control over the installation procedure to ensure their UX philosophy doesn't get compromised. GHCup has a very radical unix philosophy. Can we unify those? Probably. But when you depend on another tool/library, you're also relying on their maintainers. Now you have increased round-trip time for issues, patches, etc. because you need to communicate and can't just push fixes. Now you have to possibly debate features and so on and so on.
The easiest way forward, imo, is to first provide GHC installation user hooks for stack, which I have already implemented (as in: there is a patch). That way users get full control over how stack installs GHC, be it ghcup, nix or their own shell script code.
Everything else is reaching for the stars and won't get us anywhere atm.
I cannot think of any other major programming language whose install page says "here are several competing ways to install". That's the embarrassing situation we're in here. When we tell someone how to install Haskell, there ought to be an answer of record to that question. Note that this doesn't mean there can't be other options, such as installing from an Ubuntu PPR, or Chocolatey for Windows, or some custom setup script if Haskell is bundled into a special-use project as I already do with CodeWorld. And if someone creates a better general-purpose install tool, that answer of record can change. But right now we're paralyzing newcomers with a choice they shouldn't have to make.
I can't answer this question in regards to the proposal, since I really don't know what HF wants, what download page they envision etc. But I'm working hard towards improving the haskell.org side of this matter.
And I agree: the primary download page should NOT give choice, but make a choice. This proposal says the opposite, with the motivation to please all political parties. Except, new users don't care about that.
There was a problem hiding this comment.
I really don't know what HF wants
As a collective body, HF is unable to desire anything on its own accord, unless enshrined in meeting minutes. Tech Track meetings are open for members of public, and I encourage everyone interested to attend. Minutes of previous Tech Track meetings are available here.
There was a problem hiding this comment.
And I agree: the primary download page should NOT give choice, but make a choice. This proposal says the opposite, with the motivation to please all political parties. Except, new users don't care about that.
Okay, I was under the impression from some previous conversations with you that you did not agree with that. I'm relieved to hear we are on the same page here. I think it would be great if the Haskell Foundation proposal here would reflect that agreement. My question (for others, not for you) is: Are there parties involved who don't agree with that ultimate goal? Or is this something we all want and just have disagreements over how to get there? It's okay if we don't get there in a single step!
It seems like one way to get there would be to define an ambitious line to aim for (one that represents our authentic combined goals as a community), and concede that there will still be this not-great situation with multiple installers in the short run, but that eventually someone will hopefully cross that line, and the community can unify around that answer. That might not be the right path... who knows... but that's how I interpreted this proposal, as trying to draw that line. I don't think it's a perfect line yet, and I've left my comments as to why. But I don't think it's a non-productive conversation to have.
I'd particularly hate to see the haskell.org committee go one way, and the Haskell Foundation a different way. That would be a real blow to the community, IMO. If we're at risk of that happening, then priority number one (before passing any proposal like this one) should be to figure out why, and how we can build some consensus.
There was a problem hiding this comment.
Okay, I was under the impression from some previous conversations with you that you did not agree with that.
I was fine with this not being pursued for the sake of getting an "Installer guidelines" proposal through that tries to stay neutral. This was my collaboration effort, but I did voice that I think it's not a good idea. I do understand the concern to stay neutral. It's a different approach. It can be reasonable for other reasons. My point was simply that end users don't care.
My question (for others, not for you) is: Are there parties involved who don't agree with that ultimate goal?
We're not at the point where the involved parties have an open conversation. And so my suggestion is to postpone these discussions and not force them.
I'd particularly hate to see the haskell.org committee go one way, and the Haskell Foundation a different way.
I think haskell.org and HF are very different organizations with different approaches. The HF page says haskell.org committee is in the process of affiliation and judging from certain public comments it seems there is some effort to synchronize, but they're ultimately separate entities and can come to separate conclusions. I don't see any problem with that.
There was a problem hiding this comment.
Sorry for the delay in response. My point about the two orgs going different directions is this: to the best of my knowledge, there is not a single person who thinks a beneficial outcome from this process would be for new Haskell install instructions to be posted to haskell.foundation, while the existing instructions remain at haskell.org. That would clearly be terrible.
So if this proposal might be interpreted to say that, then it should be fixed to explicitly say that we're talking about the install instructions on haskell.org. If it cannot be fixed, or if agreement cannot be found between the haskell.org committee and the Haskell Foundation, then the proposal should be rejected, since accepting it under those circumstances would be worse than doing nothing.
This isn't meant to challenge the autonomy of either organization. It's just an observation that in this specific situation, the HF adopting a proposal at odds with haskell.org would be a disaster.
|
To be honest, I’m a bit confused with the evolution of this project. AFAIR originally it was about improving experience of Windows users, who constitute a huge fraction of Haskell industrial adopters. This is largely accomplished by recent releases of It seems like the point here is about standartisation of UI/UX of Haskell installers, but I cannot grasp specific benefits for end users. It does not strike me particularly useful to have two tools with the same UX, if that’s the goal; With regards to guidelines, I do not see why we would like to require both The sole benefit of conforming to the proposed guidelines is being featured at https://www.haskell.org/downloads/. I understand political and historical motives here, but that’s an overkill. For gods sake, let’s just continue suggesting At risk of derailing this discussion, my personal opinion is that HF would provide a better service to the community by pursuing a more ambitious goal of a deeper unification between |
You are not the only one. And I seriously think we need a reboot.
Yeah, that's what I was getting at too. I think we shouldn't standardise on UX. But we can standardise on other things:
I think these are reasonable requirements I can get behind. Portability is important. Consistent experience across platforms is important. Non-admin installation will be specifically important on windows from what I understood. Everything else about this proposal is confusing/vague. The first 3 points can be agreed upon easily. The fourth point may need some future work, but as an MVP is easy to achieve as well. |
|
|
||
| The Haskell Foundation would like see a central Haskell download page in which the Haskell curious | ||
| could easily download and run a installer to provide a standard Haskell environment that supports | ||
| the principal build tools (`cabal-install` and `stack`) on the main platforms (Linux, macOS and |
There was a problem hiding this comment.
Also: ghc and ghci. I think it's critical that someone who has installed haskell can run ghci (not cabal repl or stack exec or whatever) and try things out, for example. Not all Haskell users are building projects and need project-focused build tools.
| could easily download and run a installer to provide a standard Haskell environment that supports | ||
| the principal build tools (`cabal-install` and `stack`) on the main platforms (Linux, macOS and | ||
| Windows). All Haskell introductory material (text books, blog posts, etc.) should be able to point | ||
| to the Haskell Foundation download page and work on the assumption that it will yield their |
There was a problem hiding this comment.
I hope not! It's clear to me that haskell.org should remain the contact point for getting started with Haskell. It's where beginners will look, after all, whether they are told to or not.
| The exact configuration of Haskell development environments has recently been a contentious issue | ||
| leading to regrettable fragmentation and confusion. It should be a priority of the Haskell | ||
| Foundation to lead the way in restoring harmony for the health of the Haskell community and its | ||
| ecosystem. The Haskell Foundation should also be well placed to do this with its broad | ||
| representation at board level and many sponsors and friends in the community. |
There was a problem hiding this comment.
I strongly disagree with you here. The path may be longer than I'd like to get there amicably, but having competing installers to get started with Haskell is clearly a bad user experience, and frankly sort of an embarrassing state of affairs. I'd love for people to agree on a set of standards mainly so that we can get to the point where one installer can meet those standards and become the clear choice.
| ## 0. Objectives | ||
|
|
||
| We want people to use Haskell, which means the path to installing Haskell for first-time users | ||
| should be short and easy, and it should yield an environment that is easy to use with the supporting |
There was a problem hiding this comment.
I think this needs to be left as an issue for the collective judgement of users. My strong suspicion is that there's a use case for both interactive and non-interactive installation, and that an ideal install tool would provide both options while installing the same a well-known and standardized environment regardless of the choice of UX.
|
|
||
| * Both of the principal build systems (`cabal-install` and `stack`) should be installed, | ||
| available and ready for use in the way their associated development communities would expect. | ||
| (If an installer interrogates the user on installation about which components to install it is |
There was a problem hiding this comment.
I disagree here. It's sufficiently important to make both tools available as part of the standard Haskell environment that any tool linked to by the community as a general-purpose installer for Haskell should be installing both by default. I'd add, though, that they should also be putting ghc and ghci in the path to be run directly, since that is also an important part of a standard Haskell environment.
This language still allows for tools to provide detailed options or customization. It just says that if you install "Haskell", that includes working cabal and stack executables.
| This won't be a minimum requirement to start with but the Haskell Foundation would like to encourage | ||
| Haskell installation systems to install a core set of precompiled packages, apart from `base`, when | ||
| installing the default compiler toolchain (at least). The objective is to allow developers | ||
| (especially new developers) to be able to build certain kinds of simple applications quickly and | ||
| painlessly after a fresh installation. |
There was a problem hiding this comment.
I do see the point in this, mainly because I think the ghci use case is important. But since the libraries to be available aren't really specified, it is hard to evaluate the requirement today. In any case, it's easy enough to use cabal to install new libraries from Hackage into the default environment.
|
|
||
| Installer systems should not require as a prerequisite the installation of other major systems that | ||
| the average Haskell-curious developer would not be expected to have installed. The requirement that | ||
| `chocolatey` be already installed in order to install Haskell on Windows would be undesirable for |
There was a problem hiding this comment.
This is just an example, and it's not singling out chocolatey at all. That's just the one tool that's kludged in like this today. Whatever you think of mentioning the example, the requirement seems very reasonable. Integrating with chocolatey as an option is still fine, but I'm somewhat unhappy with the state of affairs where the download page tells Windows users that they must install some third party tool before they can even run the Haskell installer. They didn't come to get chocolatey (or whatever); they came to get Haskell.
|
Thank you to @cdornan, @hasufell, @cdsmith, @Bodigrim, @Terkwood, and @tomjaguarpaw for creating and giving thoughtful comments on this proposal. The purpose of the proposal process is exactly to get this kind of feedback and steer around avoidable issues, but in this case we clearly got out over our skis. Our initial goal was better Windows support, and between Stack’s existing Windows support and @hasufell’s work in adding it to ghcup, I consider that accomplished. However, it's clear that integrating Stack and Ghcup was contentious to begin with, and it compounded due to our inability to manage scope for this project. I want to publicly apologize to @snoyberg, @cdornan, and @hasufell for how this project has gone to date. We are making changes to the proposal process to help ensure projects go better:
|
I'm not sure the problem here really was about the process. IMO, it's:
I believe HF has a lot of work to do and the recent threads on the board mailing list about mission statement don't reinforce my trust in it. It seems more focused around appealing to industry and maintaining an image of "getting things done", that it seems there's little space left for "enabling and supporting the community". Are you working for the community or do you expect the community to work for you? |
|
I'd like to reiterate that I'm sorry that you felt you felt demanded, pressured and not supported. That is exactly the opposite of how the foundation aims to operate. The phenomena you are experiencing are not intentional. They are an emergent property of a brand new organisation getting off the ground, working hard to discover its purpose and its most effective way of operating. This is truly difficult because the group of people associated with the HF (employees, board members, track members, other volunteers) is large, diverse and distributed. I caution against interpreting any sort of intentionality into the experiences you have had with the HF. Perhaps you feel that the workings of the HF are opaque, that it's hard to know who has responsibility for what, when meetings are held, how decisions are taken. Well, I have the same experience, even as a board member! There isn't some castle wall between "The HF" and the community. Almost everything is accessible to every member of the community. There is almost no private communication. I reiterate: the HF is a new organisation and we are working on improving communication, accessibility and visibility into processes but this takes time and feedback (thank you for your feedback). Bar approximately one person[1] everyone associated with the HF is a volunteer, spending their personal time contributing to the community they love. Furthermore I'd wager that most are open source volunteers themselves, having contributed to GHC, core libraries, infrastructure and tooling for years or decades. The HF has been operating for a bit more than half a year. To me personally, who has been spending at least some part of every day volunteering on HF work, it feels like very short length of time. We haven't yet been able to overcome every challenge that has risen ahead of us but we are striving to improve. We continue to welcome general reports of experience of interacting with the HF. The totality of such reports will inform how we "steer the ship". If anyone has specific requests to make, for example for support for an open source project, specific examples of behaviour they want to see more or less of from the HF or a specific request for collaboration then those can be acted on far quicker than "steering the ship". I encourage you or anyone else in the community, if they have such specific requests, to go ahead and make them. Currently, the most appropriate forum for such requests in the HF Slack. [1] The HF has two employees but roughly 50% of their combined time is spent purely on fundraising, as is typical for a charitable foundation |
|
I'm archiving this proposal because there has not been progress for a long time. Anyone who is interested in picking it up and continuing should feel free to re-open it! |
|
In fact the aims of this proposal have largely been achieved: https://www.haskell.org/downloads/ |
I think there's value in reviving it, because there has been some confusion with haskell.org committee about distribution guidelines. @tomjaguarpaw (afaiu) found that GHCup should not modfiy code, binaries or even bindists (?) downstream. While this is mostly true as a reality, GHCup maintainers don't guarantee that this is the case and will generally reserve the right to fix bindists and even patch binaries if protecting users from grave bugs requires this. Obviously, code changes that are not upstreamed should be a very rare exception, but there are cases where linux distributions do this as well (and obviously cases where it caused chaos). This is a matter of trust between distributor and upstream and distributor and end user. We collaborate with all tool maintainers, be it GHC, Cabal, HLS or stack. A revived proposal would allow us to make this clear. If people want a "vanilla bindist" option, this could be discussed as part of the proposal, but I'll just say that most GHC versions would be broken for you then. |
It may be sufficient to require distributors to simply document their policies. |
Reviving it sounds good! It just needs someone who wants to do the work of updating and continuing it. |
No description provided.