wither the Platform

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

wither the Platform

Mark Lentczner-2
I'm wondering how we are all feeling about the platform these days....

I notice that in the new Haskell pages, the Platform is definitely not the
recommended way to go: The main download pages suggests the compiler and
base libraries as the first option - and the text for the Platform (second
option) pretty much steers folks away from it. Of the per-OS download
pages, only the Windows version even mentions it.

Does this mean that we don't want to consider continuing with it? It is a
lot of community effort to put out a Platform release - we shouldn't do it
if we don't really want it.

That said, I note that the other ways to "officially get" Haskell look, to
my eye, very ad hoc. Many of the options involve multiple steps, and
exactly what one is getting isn't clear. It hardly looks like there is now
an "official, correct" way to setup Haskell.

The Platform arose in an era before sandboxes and before curated library
sets like Stackage and LTS. Last time we set direction was several years
ago. These new features and development have clearly changed the landscape
for use to reconsider what to do.


I don't think the status quo for the Platform is now viable - mostly as
evidenced by waning interest in maintaining it. I offer several ways we
could proceed:

*1) Abandon the Platform.* GHC is release in source and binary form. Other
package various installers, with more or less things, for various OSes.

*2) Slim the Platform.* Pare it back to GHC + base + a smaller set of
"essential" libs + tools. Keeps a consistent build layout and installation
mechanism for Haskell.

*3) Re-conceive the Platform.* Take a very minimal install approach,
coupled with close integration with a curated library set that makes it
easy to have a rich canonical, stable environment. This was the core idea
around my "GPS Haskell" thoughts from last September - but there would be
much to work out in this direction.

Thoughts?

? Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150321/a7253f8e/attachment.html>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Mark Lentczner-2
Eeek! I really really did mean to make the subject *whither*, not *wither!*?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150321/37f7a016/attachment.html>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Matthias Hörmann
I can't speak for others but as a regular but enthusiastic Haskell user the
platform always (not just since sandboxes) felt outdated and limited to the
included packages since the rest of the Haskell ecosystem rapidly moved on
after a platform release (or even during its stabilization freeze phase
before a release).

The platform is quite similar to Linux distributions like Debian stable or
RedHat Enterprise Linux in that sense. Running software not in their
repositories on one of those is a bit of a pain and not for the beginner
too, just as running packages outside the HP can be when you start out with
it.

The majority of the Haskell power users (library authors, people interested
in the language development itself,...) on the other hand run Haskell more
like a rolling release Linux distribution, dealing with problems due to
cutting edge versions as they arise which means cutting Hackage versions do
not build on the HP. On the other hand new versions that do compile very
rarely seem to cause major issues, offering little incentive to use older
versions for power users outside enterprise support environments.

Perhaps Haskell does need some kind of multi-tier system as those Linux
distributions use? LTS and Stackage seem to be attempts to do just that.

In any case, I do not think the HP is the best environment for the new
Haskell user.

Perhaps listing the possible types of users and their requirements and
limitations would be helpful to decide what, if anything, should replace
the HP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150322/244c18c3/attachment.html>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Neil Mitchell
In reply to this post by Mark Lentczner-2
On Windows, the reason I used to use the Platform was that it came
with an installed network library, and installing the network library
on Windows is a real pain (and often fails). Unfortunately it was
incredibly brittle, a single attempt at upgrading network from some
newer package usually trashed my Haskell install and required a wipe
and restart.

Nowadays I use https://github.com/fpco/minghc which can actually
install network, and I've had zero problems. I can get up to the
platform with one invoke of cabal, and if someone decides to require a
new network, it just works.

I think the Platform now gives a worse user experience on Windows, so
the ideas (or names) probably need migrating around.

Thanks, Neil


On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus
<apfelmus at quantentunnel.de> wrote:

> Mark Lentczner wrote:
>>
>> I'm wondering how we are all feeling about the platform these days....
>>
>> I notice that in the new Haskell pages, the Platform is definitely not the
>> recommended way to go: The main download pages suggests the compiler and
>> base libraries as the first option - and the text for the Platform (second
>> option) pretty much steers folks away from it. Of the per-OS download
>> pages, only the Windows version even mentions it.
>>
>> Does this mean that we don't want to consider continuing with it? It is a
>> lot of community effort to put out a Platform release - we shouldn't do it
>> if we don't really want it.
>>
>> That said, I note that the other ways to "officially get" Haskell look, to
>> my eye, very ad hoc. Many of the options involve multiple steps, and
>> exactly what one is getting isn't clear. It hardly looks like there is now
>> an "official, correct" way to setup Haskell.
>>
>> The Platform arose in an era before sandboxes and before curated library
>> sets like Stackage and LTS. Last time we set direction was several years
>> ago. These new features and development have clearly changed the landscape
>> for use to reconsider what to do.
>>
>>
>> I don't think the status quo for the Platform is now viable - mostly as
>> evidenced by waning interest in maintaining it. I offer several ways we
>> could proceed:
>>
>> *1) Abandon the Platform.* GHC is release in source and binary form. Other
>> package various installers, with more or less things, for various OSes.
>>
>> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of
>> "essential" libs + tools. Keeps a consistent build layout and installation
>> mechanism for Haskell.
>>
>> *3) Re-conceive the Platform.* Take a very minimal install approach,
>> coupled with close integration with a curated library set that makes it
>> easy to have a rich canonical, stable environment. This was the core idea
>> around my "GPS Haskell" thoughts from last September - but there would be
>> much to work out in this direction.
>>
>> Thoughts?
>
>
> Thanks a lot for your hard work on the platform!
>
> I myself am an avid user of the platform (OS X), because for me, it's the
> easiest way to install Haskell on a new machine; I just did so the other
> day.
>
> The only time when the platform seems to be a handicap is when a new version
> of GHC is being released and I would have to update my packages. Usually, I
> don't test them with the new version and rely on pull requests instead.
>
>
> Best regards,
> Heinrich Apfelmus
>
> --
> http://apfelmus.nfshost.com
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Benno Fünfstück
I'd like the haskell platform to include all of LTS haskell. That includes
a very broad set of packages so you don't need to install many other
packages even as an advanced user.

Maybe there could also be a nightly release which includes stackage
instead?

It would save a lot of time even for experienced users, since they get
stackage precompiled.

However, such a distribution should be designed such that cabal install
just works, so it should probably be based on winghc on Windows.

The only problem I can see with this is the size of such a package, not
sure if it would be acceptable?

Neil Mitchell <ndmitchell at gmail.com> schrieb am So., 22. M?r. 2015 10:18:

> On Windows, the reason I used to use the Platform was that it came
> with an installed network library, and installing the network library
> on Windows is a real pain (and often fails). Unfortunately it was
> incredibly brittle, a single attempt at upgrading network from some
> newer package usually trashed my Haskell install and required a wipe
> and restart.
>
> Nowadays I use https://github.com/fpco/minghc which can actually
> install network, and I've had zero problems. I can get up to the
> platform with one invoke of cabal, and if someone decides to require a
> new network, it just works.
>
> I think the Platform now gives a worse user experience on Windows, so
> the ideas (or names) probably need migrating around.
>
> Thanks, Neil
>
>
> On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus
> <apfelmus at quantentunnel.de> wrote:
> > Mark Lentczner wrote:
> >>
> >> I'm wondering how we are all feeling about the platform these days....
> >>
> >> I notice that in the new Haskell pages, the Platform is definitely not
> the
> >> recommended way to go: The main download pages suggests the compiler and
> >> base libraries as the first option - and the text for the Platform
> (second
> >> option) pretty much steers folks away from it. Of the per-OS download
> >> pages, only the Windows version even mentions it.
> >>
> >> Does this mean that we don't want to consider continuing with it? It is
> a
> >> lot of community effort to put out a Platform release - we shouldn't do
> it
> >> if we don't really want it.
> >>
> >> That said, I note that the other ways to "officially get" Haskell look,
> to
> >> my eye, very ad hoc. Many of the options involve multiple steps, and
> >> exactly what one is getting isn't clear. It hardly looks like there is
> now
> >> an "official, correct" way to setup Haskell.
> >>
> >> The Platform arose in an era before sandboxes and before curated library
> >> sets like Stackage and LTS. Last time we set direction was several years
> >> ago. These new features and development have clearly changed the
> landscape
> >> for use to reconsider what to do.
> >>
> >>
> >> I don't think the status quo for the Platform is now viable - mostly as
> >> evidenced by waning interest in maintaining it. I offer several ways we
> >> could proceed:
> >>
> >> *1) Abandon the Platform.* GHC is release in source and binary form.
> Other
> >> package various installers, with more or less things, for various OSes.
> >>
> >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of
> >> "essential" libs + tools. Keeps a consistent build layout and
> installation
> >> mechanism for Haskell.
> >>
> >> *3) Re-conceive the Platform.* Take a very minimal install approach,
> >> coupled with close integration with a curated library set that makes it
> >> easy to have a rich canonical, stable environment. This was the core
> idea
> >> around my "GPS Haskell" thoughts from last September - but there would
> be
> >> much to work out in this direction.
> >>
> >> Thoughts?
> >
> >
> > Thanks a lot for your hard work on the platform!
> >
> > I myself am an avid user of the platform (OS X), because for me, it's the
> > easiest way to install Haskell on a new machine; I just did so the other
> > day.
> >
> > The only time when the platform seems to be a handicap is when a new
> version
> > of GHC is being released and I would have to update my packages.
> Usually, I
> > don't test them with the new version and rely on pull requests instead.
> >
> >
> > Best regards,
> > Heinrich Apfelmus
> >
> > --
> > http://apfelmus.nfshost.com
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150322/832e2cb6/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Herbert Valerio Riedel
In reply to this post by Mark Lentczner-2
On 2015-03-21 at 18:54:26 +0100, Mark Lentczner wrote:

[...]

> The Platform arose in an era before sandboxes and before curated library
> sets like Stackage and LTS. Last time we set direction was several years
> ago. These new features and development have clearly changed the landscape
> for use to reconsider what to do.

[...]

> Thoughts?

My biggest complaint about the current HP is that it pollutes the global
package database with additional packages which leak into `cabal
sandbox`es. This causes `cabal sandbox` to provide quite different
sandbox environments for HP environments compared to a non-HP
environment without those additional packages pre-installed.

Currently GHC/Cabal knows about a global package db and a user package
db (the user pkg db is is what gets replaced/shadowed by cabal
sandboxes). Maybe we need a 3rd package db sitting between the global
and the user package db that interacts better with cabal sandboxes?

Cheers,
  hvr

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Roman Cheplyaka-2
I also thought about it recently. IIRC ghc can already deal with any
number of stacked package dbs; we only need to expose this somehow
through cabal.

On 22/03/15 11:52, Herbert Valerio Riedel wrote:

> On 2015-03-21 at 18:54:26 +0100, Mark Lentczner wrote:
>
> [...]
>
>> The Platform arose in an era before sandboxes and before curated library
>> sets like Stackage and LTS. Last time we set direction was several years
>> ago. These new features and development have clearly changed the landscape
>> for use to reconsider what to do.
>
> [...]
>
>> Thoughts?
>
> My biggest complaint about the current HP is that it pollutes the global
> package database with additional packages which leak into `cabal
> sandbox`es. This causes `cabal sandbox` to provide quite different
> sandbox environments for HP environments compared to a non-HP
> environment without those additional packages pre-installed.
>
> Currently GHC/Cabal knows about a global package db and a user package
> db (the user pkg db is is what gets replaced/shadowed by cabal
> sandboxes). Maybe we need a 3rd package db sitting between the global
> and the user package db that interacts better with cabal sandboxes?
>
> Cheers,
>   hvr
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


Reply | Threaded
Open this post in threaded view
|

wither the Platform

Erik Hesselink
In reply to this post by Neil Mitchell
On Sun, Mar 22, 2015 at 10:17 AM, Neil Mitchell <ndmitchell at gmail.com> wrote:
> On Windows, the reason I used to use the Platform was that it came
> with an installed network library, and installing the network library
> on Windows is a real pain (and often fails). Unfortunately it was
> incredibly brittle, a single attempt at upgrading network from some
> newer package usually trashed my Haskell install and required a wipe
> and restart.

Slightly OT: If you ever want to prevent cabal from trying to install
a different version of a package (since you know it won't work, or
will break things) you can put something like this in your cabal
config:

  constraint: network installed

I do this for template-haskell, since it's not possible to reinstall
but cabal would occasionally try it. I can imagine it would work well
to prevent the scenario you describe with network.

Erik

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Herbert Valerio Riedel
On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote:

[...]

> I do this for template-haskell, since it's not possible to reinstall
> but cabal would occasionally try it. I can imagine it would work well
> to prevent the scenario you describe with network.

Why isn't it possible to reinstall TH (unless you also need to depend on
the `ghc` package)? We even explicitly allowed template-haskell to be
reinstallable again in Cabal as there didn't seem any reason to forbid
it anymore (it's no different than e.g. `bytestring` which is
reinstallable as well):

  https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f739150

Cheers,
  hvr

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Erik Hesselink
On Sun, Mar 22, 2015 at 11:24 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote:
>
> [...]
>
>> I do this for template-haskell, since it's not possible to reinstall
>> but cabal would occasionally try it. I can imagine it would work well
>> to prevent the scenario you describe with network.
>
> Why isn't it possible to reinstall TH (unless you also need to depend on
> the `ghc` package)? We even explicitly allowed template-haskell to be
> reinstallable again in Cabal as there didn't seem any reason to forbid
> it anymore (it's no different than e.g. `bytestring` which is
> reinstallable as well):
>
>   https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f739150

This was based on my experiences from some time ago. Looking at it
now, I think it was just that the dependencies for template-haskell
were too loose, i.e. it allowed different major versions of base. When
a new version of GHC was released and I was trying it out, it would
always try to install the older version, and this never worked. Now
that you fixed these constraints (thanks!) it seems you can reinstall,
as long as it's the same (major) version. It still prints this ominous
warning even in a sandbox:

    Warning: The following packages are likely to be broken by the reinstalls:
    ghc-7.8.3

But everything seems to be fine when passing --force. So I guess I can
remove the constraint...

Erik

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Edward Kmett-2
In reply to this post by Herbert Valerio Riedel
The original reason for the cabal hack that prevented it from trying to
reinstall template-haskell is that almost every time someone did this it
broke, silently. Then five packages later something would use template
haskell, and you'd get completely nonsensical error messages, and someone
_else_ would get the bug report. Sure there might have been a scenario in
which an expert who is working on ghc may want to reinstall the
template-haskell to get a new point release, but TH has never worked across
multiple GHC versions, and old versions shipped with very wide bounds.

Now, of course, maintainers and the trustees have the ability to
retroactively narrow bounds (and you've already done so for
template-haskell), so this view is dated. template-haskell should just be
reinstallable like everything else now.

-Edward

On Sun, Mar 22, 2015 at 6:24 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote:
>
> [...]
>
> > I do this for template-haskell, since it's not possible to reinstall
> > but cabal would occasionally try it. I can imagine it would work well
> > to prevent the scenario you describe with network.
>
> Why isn't it possible to reinstall TH (unless you also need to depend on
> the `ghc` package)? We even explicitly allowed template-haskell to be
> reinstallable again in Cabal as there didn't seem any reason to forbid
> it anymore (it's no different than e.g. `bytestring` which is
> reinstallable as well):
>
>
> https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f739150
>
> Cheers,
>   hvr
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150322/cd77c912/attachment.html>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

M Farkas-Dyck
In reply to this post by Mark Lentczner-2
On 21/03/2015, Mark Lentczner <mark.lentczner at gmail.com> wrote:
> I'm wondering how we are all feeling about the platform these days....

I say leave it to the operating system distributions.

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Yitzchak Gale
In reply to this post by Mark Lentczner-2
Mark Lentczner wrote:

> 1) Abandon the Platform?
>
> 2) Slim the Platform. Pare it back to GHC + base + a smaller set of
> "essential" libs + tools. Keeps a consistent build layout and installation
> mechanism for Haskell.
>
> 3) Re-conceive the Platform. Take a very minimal install approach, coupled
> with close integration with a curated library set that makes it easy to have
> a rich canonical, stable environment. This was the core idea around my "GPS
> Haskell" thoughts from last September - but there would be much to work out
> in this direction.

I vote for (3) but in a way that it would *not* be much work.
We should definitely do the Platform, but with much *less* work.

The most important reason we need the Platform is as
a default selection of quality basic libraries. We should not abandon
that concept. Curated package sets do not replace that - the
Platform is not just packages that build together. Nor do OS
packagers. The platform is a community-wide set of basic default
packages that are mature, well tested, all work together well,
and stable.

The second most important role of the Platform is a web site
where you can get a clear picture of how to download and install
a default Haskell installation for your platform, and a simple view
of where we are in the parade of releases. That should also continue.

The hardest work of the Platform was its role as a way to bootstrap a
Haskell installation. That is what made it so hard for HP to keep up
with GHC releases, and what consequently gave people the impression
that HP is always old. That work doesn't need to be done as part of the
Platform anymore. We should leverage other good work people are
doing to create installers, and stop doing it as part of the HP process.

The most important part of an HP release should be a cabal package
that provides the packages in the platform, at the right versions, with
a specification of the recommended GHC version as a pre-requisite.

Perhaps we can also provide an HP-branded slick installer for some
platforms that does everything in one click, built as a thin wrapper of
some existing installer. But that should not delay the official release
of an HP version. It's just a nice-to-have extra.

Once we pare down the work needed for an HP release, we should
release new versions of HP quite often - *more* often than GHC
releases, not less often.

Another thing we should fix is the (now false) impression that HP
gets in the way of installing other packages and versions due to
cabal hell. We should make "require-sandbox" the default setting
in the cabal config file. I would go further - I would add a cabal
feature to create a sandbox automatically unless "--user" or
"--global" is specified explicitly. I would make "foo installed" a
default constraint (that is easy to override) for all platform packages,
which solves virtually all cabal hell problems (assuming you are
using a sandbox) and will not keep things old if we release often.

Thanks,
Yitz

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Michael Snoyman
In reply to this post by Mark Lentczner-2
It should go without saying that the first sentiment we all likely have is
gratitude for all the work Mark has put into the platform, as well as all
of the other contributors and maintainers the platform has had over the
years. It hasn't just been work on producing the platform itself, but also
for setting up an expectation in the Haskell world for high quality,
reliable libraries. Even if the current incarnation of the platform is in
jeopardy, I hope that we continue with that attitude going forward.

I spend a lot of time working on Stackage, and obviously there's quite a
bit of overlap between Stackage, Haskell Platform, and LTS Haskell. For
purposes of this discussion, I think it's important to separate out
different features of the platform, and see how we may continue or
discontinue each individually:

1. A quality-approved set of libraries. As I see it, the process of coming
up with recommended libraries can continue completely independently of any
other work.
2. A method for installing GHC and build tools. I personally think that it
makes sense to separate out this aspect of the platform from all others.
MinGHC is an example of such a project: a minimal set of functionality for
bootstrapping a more complete Haskell development environment.
3. Prebuilt binary package databases. As I've mentioned in the past, and
others have here, there are problems with the current approach of putting
the packages in the global package database. I'd personally rather see this
aspect of the platform give way to more robust solutions.

And as we've already discussed in the past regarding GPS, there's
definitely room to add *more* to the platform with better build dependency
solving. LTS Haskell was specifically an effort to try to advance that
aspect of GPS.

Putting this together, I think it leads to a new approach for the platform:
minimalistic installers, curated package sets (ala LTS), recommended
packages (ala the current platform set), and a robust means for installing
these (e.g., cabal sandboxes). The Haskell world has advanced since the
initial HP work, maybe all that's needed now is upgrading to the newest
tooling available.

I realize I haven't put down any concrete "next steps" here. I definitely
have more ideas than I could put into this (already quite long) email. I
think a smaller task force dedicated to improving the tooling situation is
the best next step, and I'd be happy to kick off such an effort with other
interested individuals.

On Sat, Mar 21, 2015 at 7:54 PM Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> I'm wondering how we are all feeling about the platform these days....
>
> I notice that in the new Haskell pages, the Platform is definitely not the
> recommended way to go: The main download pages suggests the compiler and
> base libraries as the first option - and the text for the Platform (second
> option) pretty much steers folks away from it. Of the per-OS download
> pages, only the Windows version even mentions it.
>
> Does this mean that we don't want to consider continuing with it? It is a
> lot of community effort to put out a Platform release - we shouldn't do it
> if we don't really want it.
>
> That said, I note that the other ways to "officially get" Haskell look, to
> my eye, very ad hoc. Many of the options involve multiple steps, and
> exactly what one is getting isn't clear. It hardly looks like there is now
> an "official, correct" way to setup Haskell.
>
> The Platform arose in an era before sandboxes and before curated library
> sets like Stackage and LTS. Last time we set direction was several years
> ago. These new features and development have clearly changed the landscape
> for use to reconsider what to do.
>
>
> I don't think the status quo for the Platform is now viable - mostly as
> evidenced by waning interest in maintaining it. I offer several ways we
> could proceed:
>
> *1) Abandon the Platform.* GHC is release in source and binary form.
> Other package various installers, with more or less things, for various
> OSes.
>
> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of
> "essential" libs + tools. Keeps a consistent build layout and installation
> mechanism for Haskell.
>
> *3) Re-conceive the Platform.* Take a very minimal install approach,
> coupled with close integration with a curated library set that makes it
> easy to have a rich canonical, stable environment. This was the core idea
> around my "GPS Haskell" thoughts from last September - but there would be
> much to work out in this direction.
>
> Thoughts?
>
> ? Mark
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150322/d0cadeac/attachment.html>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Joachim Breitner-2
In reply to this post by Herbert Valerio Riedel
Hi,


Am Sonntag, den 22.03.2015, 10:52 +0100 schrieb Herbert Valerio Riedel:
> Currently GHC/Cabal knows about a global package db and a user package
> db (the user pkg db is is what gets replaced/shadowed by cabal
> sandboxes). Maybe we need a 3rd package db sitting between the global
> and the user package db that interacts better with cabal sandboxes?

this would also be great for distributions, which also provide packages
that should not (necessarily) in sandboxes, but are installed system
wide.

Greetings,
Joachim

--
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150322/9798e919/attachment-0001.sig>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Richard Eisenberg-2
I have to say that I'm quite surprised this conversation is happening at all. As far as I knew before doing some research in advance of this post, the Haskell Platform is *the* way to install Haskell on a fresh machine. It's certainly what I've relied on in getting Haskell on my machines (both MacOS 10.8). While I personally don't feel the need for the HP to have some curated set of libraries (especially now that there are other curated sets available), I do feel a strong need to have it be nice, shiny, and easy to install. At least for Mac, I don't know of a suitable replacement.

I feel like we, as a community, ask a tremendous amount from our users.* By eliminating the HP, we'll be asking more from users before they're even a proper part of community. This seems like a step in the wrong direction, to me.

Richard

* Here are a few ways in which we ask a ton from users:
- Users have to figure out which libraries to use. Many basic tasks (e.g. parsing, regular expressions) have competing packages, and it's hard to know which is appropriate.
- Users have to deal with a very intricate type system. Basic libraries (like the new Prelude, `vector`, `lens`) use this complexity to their advantage, but perhaps to newcomers' disadvantage. (I'm well aware I'm, in some degree, to blame here!)
- Users have to deal with long, intricate error messages. This comes hand-in-hand with the previous point. We GHC hackers try our best, but I know we fall short of the mark here.
- Once a year, when the new GHC comes out, everything breaks.
- Cabal hell.

In return, the community gives and gives and is ever patient with newcomers. This is wonderful, and I attribute Haskell's growth to the friendliness of the community. But we should be aware of just how steep the curve is.

On Mar 22, 2015, at 12:08 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Hi,
>
>
> Am Sonntag, den 22.03.2015, 10:52 +0100 schrieb Herbert Valerio Riedel:
>> Currently GHC/Cabal knows about a global package db and a user package
>> db (the user pkg db is is what gets replaced/shadowed by cabal
>> sandboxes). Maybe we need a 3rd package db sitting between the global
>> and the user package db that interacts better with cabal sandboxes?
>
> this would also be great for distributions, which also provide packages
> that should not (necessarily) in sandboxes, but are installed system
> wide.
>
> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>  Debian Developer: nomeata at debian.org
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Reply | Threaded
Open this post in threaded view
|

wither the Platform

Brandon Allbery
On Sun, Mar 22, 2015 at 9:35 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> I have to say that I'm quite surprised this conversation is happening at
> all. As far as I knew before doing some research in advance of this post,
> the Haskell Platform is *the* way to install Haskell on a fresh machine.
> It's certainly what I've relied on in getting Haskell on my machines (both
> MacOS 10.8). While I personally don't feel the need for the HP to have some
> curated set of libraries (especially now that there are other curated sets
> available), I do feel a strong need to have it be nice, shiny, and easy to
> install. At least for Mac, I don't know of a suitable replacement.
>

That's interesting, because http://ghcformacosx.github.io is pretty much
the only thing anyone recommends to Mac users any more, and in #haskell
people seem to actively steer everyone away from the Platform in all its
incarnations.

I think the time when the Platform release got held up for over a year
waiting for "important ghc fixes" pretty much killed all relevance for the
Platform as it currently exists. Maybe a reformulation and relaunch will
help, but from here it looks pretty doomed/dead.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150322/7e83a578/attachment.html>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Richard Eisenberg-2

On Mar 22, 2015, at 9:40 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
> That's interesting, because http://ghcformacosx.github.io is pretty much the only thing anyone recommends to Mac users any more, and in #haskell people seem to actively steer everyone away from the Platform in all its incarnations.

I do indeed think that this is interesting, because this thread is the first time I had ever heard of ghcformacosx. I've used Haskell on a Mac daily for several years now. I subscribe to (and read at least subject lines from) Haskell-cafe and Haskell mailing lists -- including Haskell Weekly News and HCAR -- though I'm only occasionally on reddit and very rarely look at #haskell. Besides, I run MacOS 10.8, and so ghcformacosx doesn't help me, anyway. (I installed 10.9 once upon a time. It slowed down my machine so much I preferred to reformat and roll back to 10.8, even though I was facing down a nasty deadline.)

At the least, this end of the debate shows me that the community has some disagreement about what today's status quo is, an important fact to settle on before charting a course for the future.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150322/4e2591b8/attachment.html>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Carter Schonwald
richarch, you should *still* be able to use the ghc-for-osx bundle, just
not launch the "help setup your path" app

eg, if you donwlaod the current release from
https://ghcformacosx.github.io/  and add
/Applications/ghc-7.8.4.app/Contents/bin/ to your path, you should be able
to use the included ghc et al on any >= 10.7 system.

a simple test would be to launch ghci as follows
/Applications/ghc-7.8.4.app/Contents/bin/ghci

ghc for osx USES the same GHC build that OS X haskell platform uses.

that said, mark HAS been the general custodian of official OS X builds
because he's been the only person who seems to be able to get docbook
working properly on osx

On Sun, Mar 22, 2015 at 9:55 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

>
> On Mar 22, 2015, at 9:40 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
>
> That's interesting, because http://ghcformacosx.github.io is pretty much
> the only thing anyone recommends to Mac users any more, and in #haskell
> people seem to actively steer everyone away from the Platform in all its
> incarnations.
>
>
> I do indeed think that this is interesting, because this thread is the
> first time I had ever heard of ghcformacosx. I've used Haskell on a Mac
> daily for several years now. I subscribe to (and read at least subject
> lines from) Haskell-cafe and Haskell mailing lists -- including Haskell
> Weekly News and HCAR -- though I'm only occasionally on reddit and very
> rarely look at #haskell. Besides, I run MacOS 10.8, and so ghcformacosx
> doesn't help me, anyway. (I installed 10.9 once upon a time. It slowed down
> my machine so much I preferred to reformat and roll back to 10.8, even
> though I was facing down a nasty deadline.)
>
> At the least, this end of the debate shows me that the community has some
> disagreement about what today's status quo is, an important fact to settle
> on before charting a course for the future.
>
> Richard
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150322/0f174847/attachment.html>

Reply | Threaded
Open this post in threaded view
|

wither the Platform

Anthony Cowley-2
In reply to this post by Richard Eisenberg-2
I'm sure we could do better at publicity, but your email made me wonder, so
the first thing I tried was a search on haskell-caf? that brings up several
threads with relevant subjects that mention ghcformacosx, including an HWN.
http://search.gmane.org/search.php?group=gmane.comp.lang.haskell.cafe&query=ghcformacosx

I believe that you haven't heard of it, but, if somebody asks about GHC on
OS X, the advice is pretty consistent.

It is pretty well the single-step, OS X-focused installer people ask for.
All that's missing is more unified branding across different operating
systems.

Anthony

On Sunday, March 22, 2015, Richard Eisenberg <eir at cis.upenn.edu> wrote:

>
> On Mar 22, 2015, at 9:40 PM, Brandon Allbery <allbery.b at gmail.com
> <javascript:_e(%7B%7D,'cvml','allbery.b at gmail.com');>> wrote:
>
> That's interesting, because http://ghcformacosx.github.io is pretty much
> the only thing anyone recommends to Mac users any more, and in #haskell
> people seem to actively steer everyone away from the Platform in all its
> incarnations.
>
>
> I do indeed think that this is interesting, because this thread is the
> first time I had ever heard of ghcformacosx. I've used Haskell on a Mac
> daily for several years now. I subscribe to (and read at least subject
> lines from) Haskell-cafe and Haskell mailing lists -- including Haskell
> Weekly News and HCAR -- though I'm only occasionally on reddit and very
> rarely look at #haskell. Besides, I run MacOS 10.8, and so ghcformacosx
> doesn't help me, anyway. (I installed 10.9 once upon a time. It slowed down
> my machine so much I preferred to reformat and roll back to 10.8, even
> though I was facing down a nasty deadline.)
>
> At the least, this end of the debate shows me that the community has some
> disagreement about what today's status quo is, an important fact to settle
> on before charting a course for the future.
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150322/b0b63f68/attachment-0001.html>

1234