Download page and Haskell Platform #176
Comments
|
I think this is a less confusing direction for the downloads page, although I'd note that the Haskell Platform website haskell.org links to is a bit slow. The platform website is also redundant given this kind of presentation, but I'd be in favor of eliding that anyway and just offering the download links for platform directly from haskell.org anyway. I'd be a lot more comfortable with this presentation of the downloads page if Stack was elided from the HP installers, minimal and full both. It would probably help if the pages better educated users on what they were actually choosing between, which exactly zero proposals for modifications to Haskell.org have attempted. It's roughly about:
You can mix and match these choices at will but each have different failure modes that vary substantially depending on user workflow. Nothing is perfect. I happen to believe based on substantial experience that Stack managed packages + Stack managed GHC is the most reliable, least fraught setup for typical users. I also recognize that it's not ideal for Nix users or people with custom build setups (elaborate Makefiles, Shake, etc.). |
|
@jaccokrijnen that's really nice looking! did you mock it up in html or just photoshop? If the former, a pointer to the files, etc. would be helpful (assuming this gets traction). |
|
I really like the presentation @jaccokrijnen. |
|
@gbaz it's some quick html, I could spend some time to make it functional but I think for the purposes of discussion the screenshot might be enough? |
|
@bitemyapp I don't really follow your reasoning on why stack should be omitted from the HP (but I'm not a stack user, maybe I'm missing something).
As far as I know these tools can easily coexist on a system
So can these tools (with the exception of haskell/haskell-platform#251)
Can you give an example? I think the actual point of discussion should be the content of the getting-started guide, somewhat based on the haskell-lang.org: Getting started
Perhaps more stuff at step 3, but this is what comes to mind for new users. This way there is also no need to directly choose between stack or cabal. From a quick look at the first five language tutorials on the wiki I find they all instruct to run
The referred documentation for setting up a project in step 3 (a wiki page?) could explain this. |
|
Perhaps "Downloads" (in the menu) should be renamed "Getting Haskell". This option is more descriptive than "Downloads" ("Downloads of what?"), and more including than the often proposed alternative, "Getting started" ("Started? I've programmed in Haskell for years!"). |
A common setup is "Getting started" pointing to "Alternative downloads", but we can hash details. Important: new users do exist and some do need to be handheld to One Way.
Yes, but:
|
|
But I actually came here (as suggested by @gbaz on Reddit) to report a current issue we should beware: for cabal we should ensure we mention a safe path, that is using sandboxes. Regarding user experience, the current https://www.haskell.org/downloads page still suggests non-sandboxed installations first:
I've seen the warning afterwards about sandboxes, but that's too late. Usability-wise that's still a trap for new users. |
Exactly.
Absolutely, that's why I'm proposing that the getting started "guide" just uses
Right, but this seems a matter of documentation, the link I imagine in step 3 on project tools should clearly explain that there are two seperate tools and probably steer newcomers to stack (it seems to have the best "new user" experience).
But who would do that? Again, it should be obvious from the documentation that these are two completely different tools.
That's concerning, can you give me more details? I have both stack and cabal on this system and never have problems running |
|
Let's clarify what most mean by "stack-managed GHC". Apparently you installed some GHC version system-wide—then stack will use it by default (up to 1.2.0). In that scenario, stack and cabal coexist as you're discussing, and There, Stack will also install and manage other GHC versions by itself as needed. That's not what we mean by "stack-managed GHC" though. We mean the scenario where no GHC can be found on the PATH, but there are only versions stack installs and knows how to find—while cabal doesn't. The advantage is: the only GHC you get is the correct one for your project. Hence @bitemyapp is adamant this is more robust and pushed stack to switch to this by default in next cycle. The disadvantage is: you lack direct access to GHCi and can't use cabal. Once this is clear, all the claims about stack-managed GHC that you disagreed with should make more sense. Regarding GHCi, a common replacement that works with stack-managed GHC is Without a project it uses the "global" project, the one where But in general, |
But that is the scenario after instelling the platform, is it not?
What do you mean with "there"? In the global PATH? I suppose not, since you mention cabal won't find it. So if I understand correctly, the point you're making is that the Running ghci with a globally installed ghc does. Which is the scenario with the platform. You get ghc+cabal and stack which may use the former ghc. I think I am missing your point.
I wasn't disagreeing per se , just asking how those scenarios are likely. And that's basically still my question: A user asking cabal to use a stack-managed ghc seems very unlikely. And I understand that there's no problem with the globally installed ghci that comes with the platform. |
|
The topic is not just "what happens if you install the HP". You also propose having a stack-only install on the webpage, so what happens there is relevant—and by now I hope it's clear *I'm not qualified to fully argue that point and I'm not sure this is the place; taking this point at face value is probably best. But since you'd like some evidence (which is reasonable), here's my 2 cents:
|
Well, this discussion was actually about @bitemyapp not being comfortable with including stack in the HP. I still haven't heard any convincing reason why this shouldn't be the case (except for the obvious open issue on system ghc). @bitemyapp 's argument on "wasted disk space" doesn't seem serious. But thanks for clarifying the situation on stack-managed ghc and its disabled ghci!
Sure, but then you're talking about stack+cabal and no global ghc? (I'd still like this confirmed: are stack-managed GHC's in PATH yes or no? If so, your concerns would make more sense to me)
With stack-only, do you mean a stack installation and no cabal/global ghc installation? I would like to think of "stack-only" describing a workflow just like a cabal-only workflow. These workflows should be part of documentation in the getting started guide and I think it should currently be biased to stack for new users. The platform installer should only be concerned with putting executables on a user's system. I think it's not necessary to go into more detail about the stack & global ghc issues, haskell/haskell-platform#251 obviously has to be solved before a next HP, whether it is on HP's side by instructing stack to no use system GHC or stack defaulting to no-system-ghc. |
|
@jaccokrijnen >@bitemyapp 's argument on "wasted disk space" doesn't seem serious. That's not the main reason at all. It's an old version of Stack and it currently has issues in how it is packaged with HP. One is that it shouldn't really default to using the system-ghc furnished by HP at all. I didn't want to get into it because I know nothing I say will make a difference here. However, in my absence if you could refrain from strawmanning my reasons, that would spare me having to reply again. Thanks! |
|
@jaccokrijnen The issue you mention is solved by a PR to stack that improves how it handles using system ghcs without msys. I've been a bit busy (and ill) lately but as far as I know the plan is to move ahead as per: https://mail.haskell.org/pipermail/haskell-community/2016-September/000184.html To that end, anything you could do to get this very nice design work ready (obviously sans text, which we can sort out later) to be merged in would be great. If its just an html dump and you want me or someone else to actually pull it into the proper binary -- I'm fine with that, if it makes things easier. I'll also be traveling a little next week but should be able to pick up and run with things the weekend after this coming. |
Stack-managed GHCs are indeed not in the PATH, as I tried to explain.
Exactly. That's also what is currently available under https://www.haskell.org/downloads#stack. Your mockup appears to still include that option.
"Stack-only" alone is ambiguous: "stack-only workflow" and "stack-only installation" mean different things. My message only talked about "stack-only installation". |
Hi @bitemyapp , sorry if this is a sensitive topic to you but I am not involved in any of the history with you and this repo. If you haven't read the above, I was actually trying to understand your concerns and weigh the pros/cons before implementing anything.
To get back at your first post:
But you did not give any explanation, I had collected these two, which seem reasonable:
And I found that: 1. Stack has an automated upgrade feature, which could be used in the installer 2. has to be solved. And yes, stack not using system-ghc seems the way to go. Furthermore, @Blaisorblade showed that mixing stack/cabal/global ghc usage is a bad idea. And I think this is an issue of documentation/getting-started (except for haskell/haskell-platform#251) and not relevant for which binaries HP puts on a system. Then I wrote this suggestion:
in which I also tried to address your second concern ("It would probably help if the pages better educated users on what they were actually choosing between"). This way, we can the "mixed workflow" issue from the actual provided binaries. Please let me know what you think about the actual contents of the discussion and point out things I might've missed. You can also pm me on reddit (spaceloop) if you don't want to discuss it here. |
|
@gbaz Thanks, I can try to get the design working, but I'd first like to have a good overview of the pros/cons before proceeding (as I wasn't involved in the discussion on the download page of last year). |
For that option, any details on getting started should just point directly to the stack documentation.
This scenario suggests having a cabal with no global ghc and the user actively trying to point cabal to a stack-managed ghc. That seems a bit unlikely. And would you agree with deferring the choice about cabal/stack to the end of the getting-started? I think that would be ideal for newcomers to the language. I really appreciate you answering all my technical questions, by the way! |
|
In sum, you're set on providing instructions that install stack through HP, instead of installing stack alone. It is certainly true that there are cases in which this works. Under that assumption, your plan makes sense. I'm not convinced by that assumption, but I'm tired of arguing for it, especially when the response to some of my arguments is just "I haven't seen convincing reasons". I don't even know if you've seen commercialhaskell/stack#2548. I don't want to argue for it again. However, it seems it has already been decided to offer the HP with stack by default by a different discussion, so I'd better let it go. I'll be unsubscribing from the thread shortly.
False. A program installer should ensure that after installation, the installed program works out-of-the-box. I've already been over this particular misconception. |
@jaccokrijnen : I take it by pros/cons you mean of the choice of how we point people? To be honest I think the discussion here has covered the bases pretty well, and I think its covered the pros/cons pretty well at this point. In discussions like these, the default assumption is that if everyone has a full understanding, something like consensus can be reached. So I can see how it might feel that you're missing some facts. since there's not really a consensus. But this issue has been discussed to death and there are still matters where it seems people have taken different evaluations of the relative weight of certain concerns. At the same time, on the haskell-community mailinglist, as has been mentioned, the idea, when proposed, of having an HP-focused downloads page paired with a "getting started" page that has a stack-based workflow (to recognize the concern that stack seems to have a better onboarding path) seemed to attract an almost all-around positive response, at least moreso than any previous suggestions. So, based on that discussion, where we seemed to find some traction and common ground, I think it would be best to proceed in that direction. |
|
I should probably get this out there officially before I get accused of backpedaling later:
In other words: I've been misquoted in the past as supporting a direction when in fact a plan I compromisingly agreed to was half implemented. Let me say clearly that I have massive reservations about what is being suggested, big concerns that the details of implementation will be suboptimal, and am only grudgingly on board with moving forward with it, despite it being contrary to community best interests and publicly stated opinions. |
|
Also, one more thing: it seems fairly obvious from a lot of these arguments around Stack vs HP that many people opposed to Stack have not actually tried it. I'm not making that accusation against any individual in particular, but I would recommend that someone who wants to express an opinion on the best way for users to get started with Haskell actually test the methods under discussion. I did exactly that with the new HP MInimal installer, which is where some of my points of concern came from. |
|
On the getting started and downloads page, I think the intention is that they both be in the top nav bar, and further that the downloads page link to the getting started page. The "next steps" from an hp download would be to direct people to the getting started page, in my understanding. |
|
That sounds good in principle. |
You're taking that out of context, I've initially commented to your concerns point by point and you have not replied to most of these comments, except for my questions (which I appreciate). I have agreed that the technical issues linked in this thread should first be resolved and that your concerns regarding mixed workflows should be addressed through proper documentation.
Again, that was said in a context. I meant that as your "binaries on a system that work out of the box", my point was that your "mixed workflow concerns" seem to me as an issue of documentation/getting-started, not as an issue of what should be part of the HP installer. I get it that it might be tiring for you to argue the same things in different places, just keep in mind I'm new in this whole infra discussion and I am trying my best to understand/make a useful first contribution. To be honest, it feels like I have to walk through a bit of a minefield in this discussion... |
|
@jaccokrijnen Just to give us some context, how much experience with using Stack do you have, and on which platforms? That may help us understand where you're coming from. |
|
Hi @snoyberg , as I have written before, I am not a stack user but use cabal-install for Haskell. I do use stack sometimes to verify if my project also builds using that tool. In case you were referring to me in
you are mistaken. I think stack is a nice piece of software and like to recommend it to new users now and then. Being a cabal user does not make me a stack opponent, I just don't feel any necessity to use it (and I think there are others like me who aren't as vocal as many stack users). Some more context: I was not involved or followed any of the earlier discussions on the haskell.org Downloads page. That might be where some of my questions were coming from. It was because of your recent blogposts and the tone of the discussion (which I absolutely disliked) that compelled me to try and make a technical contribution with a neutral tone. ... which brings me to the "context" of this specific issue:
My main technical observation is that some people are seeing problems in packaging certain software together while those concerns are actually about the accompanying documentation/getting-started guide (e.g. mixing cabal/stack workflows). |
|
To get back to the original discussion: I initially imagined this to be one page, not two. But some users might want the downloads page just to be that: a list of possible downloads (perhaps for non-newcomers). So what about this presentation? This way, it's visually clear for a newcomer where to get started while downloads is still available for others. The mock-up from my first post could then be that "Get Haskell" page (maybe without the other distributions, keeping the current downloads page as it is?)
|
I'm not. I'm trying to understand why there's such an obvious gap in understanding between you and two other commenters here giving explanations why pointing Stack users at an HP download is suboptimal. And that's really the crux of the matter here as far as I'm concerned: if someone's going to use Stack, they are almost always better off using the Stack direct download option, not the HP. Including Stack in HP does not provide meaningful benefit*, and causes additional problems. * The only "benefit" I'm aware of is that running
Apologies for that, I don't know why I didn't get notification on comments on that blog post. However, I think the majority of those questions should be addressed by the discussion here. To address some points:
This is a massive part of the problem, and something I'm seeing no recognition from on the HP side. A download page that provides all the tools without any way to use them is useless. Sure, someone determined enough to use Haskell, or who already knows how to use Haskell, can make do with that. The Haskell homepage should be for new users to get started easily. The HP is simply failing at that goal.
This is again missing the point: we're talking about "how will I use Haskell?" A collection of a bunch of tools without a means to use them is useless. HP Minimal does include the tools you mentioned. But a user is going to have a specific workflow.
Sure, HP could do that. It will make the installation significantly slower, and be a further example of why a Stack-specific download is better for Stack users.
I think the bug reports have proven this was in fact something to be afraid of. My point in all of this: trying to claim that HP is an unopinionated download option because it allows all workflows is only true at the most basic of levels. The download page proposed here is not servicing new users, only appeasing existing Haskellers who want to see HP at the top of the page. The only way I know to serve users correctly is to ask the questions:
I've answered these questions multiple times, and the Stack approach is the correct answer from all data and opinions I have. I've unfortunately not seen this kind of approach being used by advocates for an HP-centric download. |
|
I think one problem is this: you are talking about "HP workflow" including issues about documentation after downloading HP, while I am talking about HP as the installer for common Haskell tools. This thread has split in two discussions: technical questions about the installer and the contents of the downloads/getting-started page. I think we have similar concerns about the accompanying documentation for newcomers. In this issue I want to improve that documentation. And please note that my questions on your blog were about the HP installer, you have responded with answers about the download page (again, with the exception of the aforementioned issues).
Ok, so we are at the point of the discussion where I would like to be, thinking out the details of the getting started documentation. I had already suggested a simple proposal, but here it is again in case you didn't see it, with some modifications:
I like this getting-started guide because I think that
First thing would be learning Haskell "the language" (not a project/package management tool).
Stack (from all the positive things I've heard about it)
Follow this 3-step guide
I have been looking at beginner Haskell tutorials, for instance learnyouahaskell. These tutorials are focussed on the language features, not about setting up projects/managing dependencies. To me, having the tutorials work with |
I don't know what this means. I and others in this thread have all explained why the HP itself presents problems for a Stack based workflow. I'm not going to repeat those here. In addition to that, I am claiming that simply putting HP on the download page is insufficient, because new users will have no idea what to do next. If we give users recommended next steps, I'd strongly argue for them to be based on Stack. And if we know we're telling people to use Stack, HP is delivering an inferior experience. But at this point, I think I'm just repeating both myself and others in this thread, and most likely decisions will be made regardless of what I have to say. So I'm going to follow the lead of everyone else promoting Stack and bow out at this point, I have more productive ways to spend my time than fight a losing battle. |
(Note: this is just a suggestion, I hope to contribute something constructive in this recent heated discussion)
As @gbaz mentioned here:
Here's a quick mock-up:
Other distributions would include Stack and HP full with a more technical motivation (e.g. Haskell platform about the extra libs, why that may be useful for limited network access etc.)
After reading through the recent discussions, it seems that this would address most problems:
I've only seen two convincing technical arguments in the stack vs HP discussion.
The text was updated successfully, but these errors were encountered: