Hi Mikhal
Thank you for stepping up to be the Cabal "chair".
| Yes, there will be a release of Cabal/cabal-install together with GHC
| 8.
Can I ask what will be in it? Specifically, I would love to know
what you plan concerning the issues in this snip:
| As I understand it, the idea is that for the GHC 8.0 release
| we will also have a new Haskell Platform. And that new HP will
| not suffer from at least some of the flaws that have caused angst
| in the past.
|
| The message from Mark and Michael is attached, but it dates back
| to July. Since then Mark has stood down, and Gershom has taken
| over (thanks Gershom). So I have a number of questions
| • Does the plan (attached) remain the same?
| • What development work (if any) , in HP or Cabal or
| stack, is needed to achieve that? Is it done, or in
| progress, or not started?
| • GHC has for some time had the hooks to install multiple
| instances of the same library without conflict, but Cabal
| does not (or did not). I know Duncan was planning to do
| this. Will the Cabal that comes with HP 8.0 have this ability?
|
| I ask because there is lots of traffic about getting GHC 8.0
| ready for release, but I haven’t seen any about HP or Cabal.
| Maybe I’m just not on the right mailing lists.
|
| Regardless, would it be worth some announcements so that the
| Haskell community knows the plan? If I don’t know, probably
| many others do not.
I enclose three replies to that message, but the discussion
never converged to a conclusion.
Since then Gershom did send an update about the HP, also attached,
but that didn't cover Cabal.
Much of this this pre-dates when you became chair, so you won't
have seen it before, but you will be very familiar with the issues.
I'd love to know in more detail what you plan for Cabal and cabal-install,
esp concerning choices (1) and (2) outlined in Edward Yang's message attached.
thanks again
Simon
--- Begin Message ---
tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping
pre-built packages, so we banish cabal hell, and have a single common way to
'get Haskell' that just works.
At ICFP '14, there were several long group discussions of the state of "getting
Haskell", including Haskell Platform, Stackage, and other approaches. Over the
last year, there have been a few more public discussions and evolution on the
ideas, and other installer developments. In particular, Stackage's LTS package
sets are a direct development from this work, and the release of stack has
offered new options.
Today, drawing from all this good work and ideas from so many, we'd would like
to propose a concrete plan:
* Haskell Platform becomes the standard way to get GHC and related tools:
alex, cabal, happy, hscolour, and stack. It's a user-friendly, cross-platform
installer that gives a standard way to "get Haskell" for most users.
* Use the stack model for package installation:
* The global db has only the GHC packages
* There is a package db for each curated set, Haskell Platform becomes
one such set
* Projects each have their own package db, much like sandboxes.
* Haskell Platform's installer will no longer include pre-built,
pre-installed packages other than GHC's set. Instead, it is configured so that
stack can be used to build and install, on as needed, the corresponding Haskell
Platform release packages.
We think this plan solves many different community needs:
* We have a clear way to "get Haskell" that works for a wide variety of
use cases.
* HP installer gets much smaller, and about as minimal as a working
installation can get.
* By leaving most packages out of the global database, users of
cabal-install, will now have far fewer problems. Sandbox builds should now
never give users "cabal hell" like warnings.
* By building and installing the Platform packages into it's own package
db, users get the benefit of building and installing these common packages only
once per system, yet can easily bypass them for any given project if desired.
* Since the Platform packages are now built and installed as needed,
installing on smaller systems or servers without OpenGL will work.
To do this, we have a bit of work ahead of us: We need to settle on
installation layout for each OS (including getting msys into the Windows
installer); decide on the naming and versioning of the Platform package set (is
it just LTS? does it have a different life cycle? etc...); getting stack ready
such a distribution; and configuring (or updating) cabal-install to support the
three-layer package db scheme. We think we can do this in short order.
We recognize this represents a significant change for the Platform, and will
require buy-in from the various parts, especially ghc, cabal, and stack. We'd
like to get your input.
- Michael & Mark
_______________________________________________
ghc-devs mailing list
ghc-d...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--- End Message ---
--- Begin Message ---
Hello Simon,
> · GHC has for some time had the hooks to install multiple
> instances of the same library without conflict, but Cabal does not (or
> did not). I know Duncan was planning to do this. Will the Cabal
> that comes with HP 8.0 have this ability?
A month ago I wrote a blog post attempting to poll the community
on whether or not we should wait for Duncan's patchset, or directly
forge ahead and enable no-reinstall. There was subsequent discussion
on Reddit.
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fblog.ezyang.com%2f2015%2f09%2fis-no-reinstall-cabal-coming-to-ghc-8%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c72264ec38b0442a410c808d2e245eb10%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=FZt6ptLhLCOYUJDIuzvS6JEuDjuCMy1V1WrHBDoHnEo%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.reddit.com%2fr%2fhaskell%2fcomments%2f3lilqh%2fis_noreinstall_cabal_coming_to_ghc_80%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c72264ec38b0442a410c808d2e245eb10%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IotCx6hShbde5tIohJdtCok7epWc3TjVLn3INTZD9uk%3d
I decide to look at the discussion again, and I think there
is consensus to implement this plan for HP 8.0:
1. We add a new flag, --enable-multiple-reinstalls, which turns
on the "no reinstall" behavior for GHC 7.10 and later (which
we do have a patch for).
2. When the package plan would cause conflicts, we instead
ask the user if they would like to add the flag
--enable-multiple-reinstalls (in place of where we suggest
--force-reinstalls)
I don't think the patch is hard and I will write it when I get a chance.
Edward
--- End Message ---
--- Begin Message ---
On Sat, 2015-10-31 at 21:47 +0000, Simon Peyton Jones wrote:
> · GHC has for some time had the hooks to install multiple
> instances of the same library without conflict, but Cabal does not (or
> did not). I know Duncan was planning to do this. Will the Cabal
> that comes with HP 8.0 have this ability?
On this specific point, I've been working on this a lot recently. We'll
be merging the new stuff into the main cabal-install development branch
relatively soon. However that's not the end of the story. At this point
in time I cannot say for certain if this new stuff will be on by default
in the cabal-install we release to go with ghc 8.0, though I'm confident
it would at least be included as a non-default tech preview.
So we should work out when our cut-off time is when we have to decide if
we can use this new code or if we have to go with an interim solution.
Gershom, Austin and Ben and I should chat about this to work out the
timing.
--
Duncan Coutts, Haskell Consultant
Well-Typed LLP,
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.well-typed.com%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c124237f8537443013b4908d2e2468acb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ipMW61UX0LWjHJ7eVOHQdJwkGAThq%2bGB819EQU3U4CU%3d
--- End Message ---
--- Begin Message ---
CC: Randy Polen who has done work on the windows HP installer.
I also have a patch to cabal sitting around that I would really like
pulled. (Duncan, Ed, help me out here? :-))
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fhaskell%2fcabal%2fpull%2f2820&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf2b99314331343b86e6c08d2e248ca44%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0IiqCw3MXEkrXxECRViyk7BJlYb1YRRV2460%2bzXBCIc%3d
This "default global constraints" option would provide an appropriate
fallback if the *nix stuff is not considered ready for primetime,
allowing global pinning of platform packages even absent shipping the
binaries.
In fact, with a minimal platform we don't even need to enforce one or
the other choice (or just not having a choice and using sandboxes
everywhere).
So I would like this patch pulled.
There seems to be a controversy though with the "no-reinstall" cabal
-- Plan Ed and Plan Duncan seem to involve different patchsets towards
roughly the same end. I gather people think Duncan's set would be more
comprehensive, but consider it less done? Either way, it would be good
for Duncan to confirm the relationship of the two sets and if it is
indeed a binary option between the two (which I understand to be the
case?).
Finally, on the other element of new platform -- there is a patch
already pulled to Cabal that enables a nicer interaction with msys
(https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fhaskell%2fcabal%2fpull%2f2840&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf2b99314331343b86e6c08d2e248ca44%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jVd97wv9RHtF7JhQN18XmpBoZDMoxWE1XQ%2b8IIopTU8%3d).
I think we need to go
through the platform and try to use a version with this patch to
implement msys interaction, and also to teach it to install the now
requested "official" mys installs (e.g. pointed to here:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ffpco%2fstackage-content%2fblob%2fmaster%2fstack%2fstack-setup-2.yaml%23L20&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf2b99314331343b86e6c08d2e248ca44%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=C7Tqk%2fV3O7chgN2bd7Nbv8EDbRGBiQEC%2bg3JhSIwnLo%3d).
I've been meaning to both do some actual work modifying the platform
build process (just to build less packages -- so, hopefully, easy!)
and put out a note about this, but got rather slammed by work
immediately following Haskell Exchange, and have just started to come
up for air.
Cheers,
Gershom
On Sat, Oct 31, 2015 at 6:56 PM, Duncan Coutts <dun...@well-typed.com> wrote:
> On Sat, 2015-10-31 at 21:47 +0000, Simon Peyton Jones wrote:
>
>> · GHC has for some time had the hooks to install multiple
>> instances of the same library without conflict, but Cabal does not (or
>> did not). I know Duncan was planning to do this. Will the Cabal
>> that comes with HP 8.0 have this ability?
>
> On this specific point, I've been working on this a lot recently. We'll
> be merging the new stuff into the main cabal-install development branch
> relatively soon. However that's not the end of the story. At this point
> in time I cannot say for certain if this new stuff will be on by default
> in the cabal-install we release to go with ghc 8.0, though I'm confident
> it would at least be included as a non-default tech preview.
>
> So we should work out when our cut-off time is when we have to decide if
> we can use this new code or if we have to go with an interim solution.
> Gershom, Austin and Ben and I should chat about this to work out the
> timing.
>
> --
> Duncan Coutts, Haskell Consultant
> Well-Typed LLP,
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.well-typed.com%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf2b99314331343b86e6c08d2e248ca44%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mMV%2f18KhtzDZApsmYbHBCCQWecLgMxiGYP%2fFqE3uPy0%3d
>
--- End Message ---
--- Begin Message ---
Dear all,
As you know, Mark has passed on the Haskell Platform maintainer hat to me.
I wanted to give a heads-up on current plans to keep folks in the
loop. This message has three sections, first the 7.10.3 release, next
the 8.0 release, and finally some general musings on fiddly details
and future plans.
1) 7.10.3
The 7.10.3 release candidates have been out for windows and unix for a
bit. As I understand it there is still work underway on the mac build,
but that will hopefully be coming shortly. The plan is to release a
new platform roughly simultaneously. This platform will work
essentially as in the past, for two reasons. First, because it is the
last release in the 7.10 series and should be seen like the 7.10.3
compiler as just incorporating some necessary patches rather than any
serious changes. Furthermore, the future plans underway rely on a few
patches to cabal which have been merged, but are not yet in any
existing cabal-install release. A few packages have received minor
version bumps, as follows:
PACKAGE 7.10.2-a latest
-------------------------------------------
case-insensitive 1.2.0.4 1.2.0.5
fgl 5.5.2.0 5.5.2.3
GLUT 2.7.0.1 2.7.0.3
GLURaw 1.5.0.1 1.5.0.2
HUnit 1.2.5.2 1.3.0.0
OpenGL 2.12.0.1 2.13.1.0
OpenGLRaw 2.5.1.0 2.6.0.0
primitive 0.6 0.6.1.0
syb 0.5.1 0.6
scientific 0.3.3.8 0.3.4.2
StateVar 1.1.0.0 1.1.0.1
A few packages were held back due to dependency issues (notably zlib)
and additionally, packages shipped with ghc were held back to the
versions that will be shipped with 7.10.3.
2) 8.0
We also plan to ship a new platform concurrently with the ghc 8.0 that
should be released early next year.
That platform will implement some long-discussed and requested
changes. First, the platform already ships with msys on windows.
However, it does not do so in a way that lets you, as with minGHC,
install the network library directly, or for that matter install
directly other libraries that use build-type configure. This is
because the msys binaries don't get placed into the path, by design.
The new platform will ship with a newer cabal, incorporating a patch
(pull request #2480) that uses the extra-prog-path setting for
build-type: configure. This should allow network and other things
reliant on build-type: configure to directly cabal install. The goal
for the platform on windows will be that any packages binding to msys
libraries _should_ be cabal installable without hassle. If you
maintain a library that you think would be a good test-case for this,
please drop a line so we can work together towards this goal.
Second, the default platform will be _minimal_. That is to say that it
will _only_ install into the global package database those packages
that are directly shipped with ghc, and not any additional platform
packages.
"Blessed" platform packages will however still be shipped as a
"default user cabal.config" file, so in a setting where users want to
work unsandboxed, their versions of platform libs will remain pegged
to those chosen by the platform, should they not choose to alter their
settings. In a sandboxed setting, or in the presence of a local
cabal.config generated by a freeze, those constraints will be
disregarded.
Furthermore, it is likely but not certain that the "nix-like cabal" or
"no-reinstall cabal" will be available for the 8.0 release. If this is
the case, users will be able to operate in an unsandboxed environment
without conflicts, as multiple instances of the same version of a
package, with different dependency choices, will be able to live
side-by-side.
Third, the platform will ship not only with cabal-install, but also
with the stack tool, so that users can choose either workflow,
depending on their project or preferences. A number of people have
adopted the stack tool, and many beginners have reported success with
it as well, so it will be good to provide that functionality out of
the box with every platform install.
Time and resources permitting we would also like to ship a platform
version _with_ the platform libraries prebuilt and included, as that
is also a use case that some people continue to like. However, this is
a secondary priority, and contingent on us getting our build
infrastructure into a good enough shape to make this not too much
extra hassle.
I'm excited about these changes, and confident we can get their in a
timespan that matches the 8.0 release of ghc.
3) Generalities
As I mentioned, it would be good to have a more uniform build
infrastructure. Generally, I have put out some feelers and am working
towards extending the ghc nightly buildbot infrastructure to both
cover more platforms and also cover more tools -- not only ghc, but
cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get
an economy of scale and many of our core tools will be able to all
share regular automated builds across many platforms. If you like
CI/buildbot systems and would like to help out with this project,
please reach out.
Also, once we've modernized and fixed up the core platform installer
tech, it would be nice to move back to the process of making the
platform a good set of blessed libraries -- taking more proposals for
additions to it, looking to cull libraries that are no longer widely
used, etc. As part of this I intend to move the haskell-platform list
off our deprecated
https://na01.safelinks.protection.outlook.com/?url=community.haskell.org&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c7a6025717ff54e1b853f08d2ebe7aad0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IY2bNqZaHXTMZPEqZ5CnMfHbKsCHa%2f5bRDTAl8jMhRs%3d
infrastructure and onto
https://na01.safelinks.protection.outlook.com/?url=mail.haskell.org&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c7a6025717ff54e1b853f08d2ebe7aad0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=e8%2fVyHJ4GtJxZoExjkh9PO%2byeTSXjsjC%2fX0gIxUWcwQ%3d
with our other active lists.
Finally, I'm happy to be maintainer of the platform through this
period of change and transition, but at some future point, as things
get sorted out and the release process becomes more standard and
mechanical, I would very much like to pass this responsibility on. I
have had some nibbles of offers, but if other people want to begin to
get involved, please let me know and we can start to get small
contributions from you so that you can become familiar with the
various tech and systems involved.
The Haskell ecosystem is a team effort, a collective project, and
volunteer driven. In my modest experience hacking on the various
systems involved (cabal, cabal-install, hackage, the platform build,
etc.) some are a bit confusing, but I have always found helpful
contributors willing to explain things and review patches, and to help
think about and diagnose problems. And none of the code has been as
confusing as things I've had to wade through for employment-related
purposes :-). So when this stuff doesn't work as well as we'd like, we
can investigate together, and then put our heads together and figure
out how to improve it together. Furthermore, it can be very satisfying
to do so, because the impact of those improvements makes itself widely
felt. I look forward to more people joining in!
Best,
Gershom
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fcabal-devel&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c7a6025717ff54e1b853f08d2ebe7aad0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nggR6hWY%2fCnXGGVx1%2blX%2bu%2fZHAhQA%2bFnkNTlPe4El40%3d
--- End Message ---
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
