From fa-ml at ariis.it  Tue Mar  3 14:58:47 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Tue, 3 Mar 2015 15:58:47 +0100
Subject: [patch] lincenses warning
Message-ID: <20150303145847.GA29475@x60s.casa>

Dear Cabal developers,
    spurred by this discussion on haskell-cafe [1], I attach a small patch
on licence warnings. It:

    - reverts AllRightsReserved as PackageDistInexcusable, as it was
      before this commit [2].
      Reading the comments in Check.hs, this datatype is for issues which
      "[are] OK in the author's environment but [are] almost certain to be
      a portability problems for other environments", which I think it is
      the case.

    - adds a PackageDistSuspicious warning on OtherLicense. The text of
      the warning encourages the developer to choose from licences
      suggested by the OSI or FSF, if they don't want to use a licence
      recognised by cabal.

Thanks
-Francesco


[1] http://mail.haskell.org/pipermail/haskell-cafe/2015-February/118411.html
[2] https://github.com/haskell/cabal/commit/8d449ba3231445726272eac4dcf7b2b4a5508db9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: license_warnings.patch
Type: text/x-diff
Size: 1375 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150303/fed2f4cd/attachment.patch>

From gershomb at gmail.com  Tue Mar  3 18:56:15 2015
From: gershomb at gmail.com (Gershom B)
Date: Tue, 3 Mar 2015 13:56:15 -0500
Subject: [patch] lincenses warning
In-Reply-To: <20150303145847.GA29475@x60s.casa>
References: <20150303145847.GA29475@x60s.casa>
Message-ID: <CAM8RHpE-jK6ERLY7BJaQTaO1SJWq=DNjaO-7ZBC6OY7Ye15seA@mail.gmail.com>

Thanks for this patch!

I've kicked off a discussion with hackage administrators and the haskell
committee about the general approach we want to take to the license
situation on hackage, and how to properly document our policies. It seems
to me that merging this makes sense regardless, but I don't know what
others may think?

Cheers,
Gershom


On Tue, Mar 3, 2015 at 9:58 AM, Francesco Ariis <fa-ml at ariis.it> wrote:

> Dear Cabal developers,
>     spurred by this discussion on haskell-cafe [1], I attach a small patch
> on licence warnings. It:
>
>     - reverts AllRightsReserved as PackageDistInexcusable, as it was
>       before this commit [2].
>       Reading the comments in Check.hs, this datatype is for issues which
>       "[are] OK in the author's environment but [are] almost certain to be
>       a portability problems for other environments", which I think it is
>       the case.
>
>     - adds a PackageDistSuspicious warning on OtherLicense. The text of
>       the warning encourages the developer to choose from licences
>       suggested by the OSI or FSF, if they don't want to use a licence
>       recognised by cabal.
>
> Thanks
> -Francesco
>
>
> [1]
> http://mail.haskell.org/pipermail/haskell-cafe/2015-February/118411.html
> [2]
> https://github.com/haskell/cabal/commit/8d449ba3231445726272eac4dcf7b2b4a5508db9
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150303/9afaaab2/attachment.html>

From carter.schonwald at gmail.com  Sat Mar  7 05:50:19 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 7 Mar 2015 00:50:19 -0500
Subject: [patch] lincenses warning
In-Reply-To: <CAM8RHpE-jK6ERLY7BJaQTaO1SJWq=DNjaO-7ZBC6OY7Ye15seA@mail.gmail.com>
References: <20150303145847.GA29475@x60s.casa>
 <CAM8RHpE-jK6ERLY7BJaQTaO1SJWq=DNjaO-7ZBC6OY7Ye15seA@mail.gmail.com>
Message-ID: <CAHYVw0yRCyk0k60XrLOkyQzM7fT488+D0MTD1cSPrpGwFZVS+g@mail.gmail.com>

i'm very uncomfortable with the "warn on other-license" change. I think
theres lots of valid reasons that someone may be using an amended license
(eg BSD / MIT plus an explicit patent license grant) that strictly more
open/free than any standard OSS license on the planet.

Edward Kmett raise the valid point on IRC that by current international
treaties, authors no longer need to mark their works "All rights reserved"
to protect their copy right, but rather that if no other license is
specified, ANY work is by definition all rights reserved!

anyways, thats my 2cents for the evening

cheers-Carter

On Tue, Mar 3, 2015 at 1:56 PM, Gershom B <gershomb at gmail.com> wrote:

> Thanks for this patch!
>
> I've kicked off a discussion with hackage administrators and the haskell
> committee about the general approach we want to take to the license
> situation on hackage, and how to properly document our policies. It seems
> to me that merging this makes sense regardless, but I don't know what
> others may think?
>
> Cheers,
> Gershom
>
>
> On Tue, Mar 3, 2015 at 9:58 AM, Francesco Ariis <fa-ml at ariis.it> wrote:
>
>> Dear Cabal developers,
>>     spurred by this discussion on haskell-cafe [1], I attach a small patch
>> on licence warnings. It:
>>
>>     - reverts AllRightsReserved as PackageDistInexcusable, as it was
>>       before this commit [2].
>>       Reading the comments in Check.hs, this datatype is for issues which
>>       "[are] OK in the author's environment but [are] almost certain to be
>>       a portability problems for other environments", which I think it is
>>       the case.
>>
>>     - adds a PackageDistSuspicious warning on OtherLicense. The text of
>>       the warning encourages the developer to choose from licences
>>       suggested by the OSI or FSF, if they don't want to use a licence
>>       recognised by cabal.
>>
>> Thanks
>> -Francesco
>>
>>
>> [1]
>> http://mail.haskell.org/pipermail/haskell-cafe/2015-February/118411.html
>> [2]
>> https://github.com/haskell/cabal/commit/8d449ba3231445726272eac4dcf7b2b4a5508db9
>>
>> _______________________________________________
>> cabal-devel mailing list
>> cabal-devel at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>>
>>
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150307/836fd8a5/attachment.html>

From gershomb at gmail.com  Sat Mar  7 05:53:48 2015
From: gershomb at gmail.com (Gershom B)
Date: Sat, 7 Mar 2015 00:53:48 -0500
Subject: [patch] lincenses warning
In-Reply-To: <CAHYVw0yRCyk0k60XrLOkyQzM7fT488+D0MTD1cSPrpGwFZVS+g@mail.gmail.com>
References: <20150303145847.GA29475@x60s.casa>
 <CAM8RHpE-jK6ERLY7BJaQTaO1SJWq=DNjaO-7ZBC6OY7Ye15seA@mail.gmail.com>
 <CAHYVw0yRCyk0k60XrLOkyQzM7fT488+D0MTD1cSPrpGwFZVS+g@mail.gmail.com>
Message-ID: <etPan.54fa927c.1f16e9e8.eddb@mbp.local>

Well on ?other license? it should just warn that it _should be_ an open source license to be uploaded to hackage. That seems fine to me ? its an informational message.

Also note that we don?t accept packages with no license, just as we don?t accept AllRights licenses. So yes, the ?no license? fact is true, but irrelevant.

?g


On March 7, 2015 at 12:50:39 AM, Carter Schonwald (carter.schonwald at gmail.com) wrote:
> i'm very uncomfortable with the "warn on other-license" change. I think
> theres lots of valid reasons that someone may be using an amended license
> (eg BSD / MIT plus an explicit patent license grant) that strictly more
> open/free than any standard OSS license on the planet.
>  
> Edward Kmett raise the valid point on IRC that by current international
> treaties, authors no longer need to mark their works "All rights reserved"
> to protect their copy right, but rather that if no other license is
> specified, ANY work is by definition all rights reserved!
>  
> anyways, thats my 2cents for the evening
>  
> cheers-Carter
>  
> On Tue, Mar 3, 2015 at 1:56 PM, Gershom B wrote:
>  
> > Thanks for this patch!
> >
> > I've kicked off a discussion with hackage administrators and the haskell
> > committee about the general approach we want to take to the license
> > situation on hackage, and how to properly document our policies. It seems
> > to me that merging this makes sense regardless, but I don't know what
> > others may think?
> >
> > Cheers,
> > Gershom
> >
> >
> > On Tue, Mar 3, 2015 at 9:58 AM, Francesco Ariis wrote:
> >
> >> Dear Cabal developers,
> >> spurred by this discussion on haskell-cafe [1], I attach a small patch
> >> on licence warnings. It:
> >>
> >> - reverts AllRightsReserved as PackageDistInexcusable, as it was
> >> before this commit [2].
> >> Reading the comments in Check.hs, this datatype is for issues which
> >> "[are] OK in the author's environment but [are] almost certain to be
> >> a portability problems for other environments", which I think it is
> >> the case.
> >>
> >> - adds a PackageDistSuspicious warning on OtherLicense. The text of
> >> the warning encourages the developer to choose from licences
> >> suggested by the OSI or FSF, if they don't want to use a licence
> >> recognised by cabal.
> >>
> >> Thanks
> >> -Francesco
> >>
> >>
> >> [1]
> >> http://mail.haskell.org/pipermail/haskell-cafe/2015-February/118411.html  
> >> [2]
> >> https://github.com/haskell/cabal/commit/8d449ba3231445726272eac4dcf7b2b4a5508db9  
> >>
> >> _______________________________________________
> >> cabal-devel mailing list
> >> cabal-devel at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> >>
> >>
> >
> > _______________________________________________
> > cabal-devel mailing list
> > cabal-devel at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> >
> >
>  


From fa-ml at ariis.it  Sat Mar  7 20:43:55 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sat, 7 Mar 2015 21:43:55 +0100
Subject: [patch] lincenses warning
In-Reply-To: <CAHYVw0yRCyk0k60XrLOkyQzM7fT488+D0MTD1cSPrpGwFZVS+g@mail.gmail.com>
References: <20150303145847.GA29475@x60s.casa>
 <CAM8RHpE-jK6ERLY7BJaQTaO1SJWq=DNjaO-7ZBC6OY7Ye15seA@mail.gmail.com>
 <CAHYVw0yRCyk0k60XrLOkyQzM7fT488+D0MTD1cSPrpGwFZVS+g@mail.gmail.com>
Message-ID: <20150307204355.GA16178@x60s.casa>

On Sat, Mar 07, 2015 at 12:50:19AM -0500, Carter Schonwald wrote:
> i'm very uncomfortable with the "warn on other-license" change. I think
> theres lots of valid reasons that someone may be using an amended license
> (eg BSD / MIT plus an explicit patent license grant) that strictly more
> open/free than any standard OSS license on the planet.

I had a brief chat with dcoutts on freenode/#hackage, he informed me
he would rather have the AllRightsReserved patch on hackage-server
(and only in the public server branch) rather than cabal.

dcoutts also expressed similar objections on OtherLicense's warning
(on the ground that dual licensing isn't supported by cabal yet, a
a legitimate usage of OtherLicense).

My view is that, with an expressive enough License datatype which covers
an ample portion of usages, the warning could still be pragmatically
useful ("do you really have a reason to draft a new document when there
is probably something tried and tested out there which could do for your
case?").

Thanks for sharing your opinion!

From carter.schonwald at gmail.com  Sun Mar  8 17:19:34 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 8 Mar 2015 13:19:34 -0400
Subject: [patch] lincenses warning
In-Reply-To: <20150307204355.GA16178@x60s.casa>
References: <20150303145847.GA29475@x60s.casa>
 <CAM8RHpE-jK6ERLY7BJaQTaO1SJWq=DNjaO-7ZBC6OY7Ye15seA@mail.gmail.com>
 <CAHYVw0yRCyk0k60XrLOkyQzM7fT488+D0MTD1cSPrpGwFZVS+g@mail.gmail.com>
 <20150307204355.GA16178@x60s.casa>
Message-ID: <CAHYVw0zTezHe1Y-4qquCH_CtC8tNBevk-xVwuDECzpzWA=vbJA@mail.gmail.com>

there will never be an expressive enough licenses datatype. Law is
complicated and fluid and changing. Period.

On Sat, Mar 7, 2015 at 3:43 PM, Francesco Ariis <fa-ml at ariis.it> wrote:

> On Sat, Mar 07, 2015 at 12:50:19AM -0500, Carter Schonwald wrote:
> > i'm very uncomfortable with the "warn on other-license" change. I think
> > theres lots of valid reasons that someone may be using an amended license
> > (eg BSD / MIT plus an explicit patent license grant) that strictly more
> > open/free than any standard OSS license on the planet.
>
> I had a brief chat with dcoutts on freenode/#hackage, he informed me
> he would rather have the AllRightsReserved patch on hackage-server
> (and only in the public server branch) rather than cabal.
>
> dcoutts also expressed similar objections on OtherLicense's warning
> (on the ground that dual licensing isn't supported by cabal yet, a
> a legitimate usage of OtherLicense).
>
> My view is that, with an expressive enough License datatype which covers
> an ample portion of usages, the warning could still be pragmatically
> useful ("do you really have a reason to draft a new document when there
> is probably something tried and tested out there which could do for your
> case?").
>
> Thanks for sharing your opinion!
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150308/6d243af5/attachment.html>

From fa-ml at ariis.it  Sun Mar  8 20:32:30 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sun, 8 Mar 2015 21:32:30 +0100
Subject: [patch] lincenses warning
In-Reply-To: <CAHYVw0zTezHe1Y-4qquCH_CtC8tNBevk-xVwuDECzpzWA=vbJA@mail.gmail.com>
References: <20150303145847.GA29475@x60s.casa>
 <CAM8RHpE-jK6ERLY7BJaQTaO1SJWq=DNjaO-7ZBC6OY7Ye15seA@mail.gmail.com>
 <CAHYVw0yRCyk0k60XrLOkyQzM7fT488+D0MTD1cSPrpGwFZVS+g@mail.gmail.com>
 <20150307204355.GA16178@x60s.casa>
 <CAHYVw0zTezHe1Y-4qquCH_CtC8tNBevk-xVwuDECzpzWA=vbJA@mail.gmail.com>
Message-ID: <20150308203230.GA17183@x60s.casa>

On Sun, Mar 08, 2015 at 01:19:34PM -0400, Carter Schonwald wrote:
> On Sat, Mar 7, 2015 at 3:43 PM, Francesco Ariis <fa-ml at ariis.it> wrote:
> > My view is that, with an expressive enough License datatype which covers
> > an ample portion of usages, the warning could still be pragmatically
> > useful ("do you really have a reason to draft a new document when there
> > is probably something tried and tested out there which could do for your
> > case?").
>
> there will never be an expressive enough licenses datatype. Law is
> complicated and fluid and changing. Period.

Well, I ran a little test on the index of packages [1], to check the most
popular licences there and see how widespread is the use of OtherLicense.

BSD3 5007
MIT 976
GPL 460
OtherLicense 307
GPL-3 286
PublicDomain 199
LGPL 145
GPL-2 81
Apache-2.0 53
LGPL-3 51
LGPL-2.1 49
parse-error 43
none 36
BSD2 23
AGPL-3 21
BSD3  8
BSD4 5
OtherLicense  3
Apache License, Version 2.0 3
LGPL-2 2
<Misc> 13

Parsing was extremely crude, but enough to conclude that OtherLicense
amounts to less than 4% of the total amount of packages (7771).

If we find a way to deal with dual licences and add some missing licences
to Cabal (e.g. Artistic License 2), the Licence datatype will cover
99%+ of usage, which is expressive enough in my opinion (and it's not
we cannot add more stuff as new licenses pop up).


[1] https://hackage.haskell.org/packages/index.tar.gz


From carter.schonwald at gmail.com  Mon Mar  9 00:58:27 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 8 Mar 2015 20:58:27 -0400
Subject: [patch] lincenses warning
In-Reply-To: <20150308203230.GA17183@x60s.casa>
References: <20150303145847.GA29475@x60s.casa>
 <CAM8RHpE-jK6ERLY7BJaQTaO1SJWq=DNjaO-7ZBC6OY7Ye15seA@mail.gmail.com>
 <CAHYVw0yRCyk0k60XrLOkyQzM7fT488+D0MTD1cSPrpGwFZVS+g@mail.gmail.com>
 <20150307204355.GA16178@x60s.casa>
 <CAHYVw0zTezHe1Y-4qquCH_CtC8tNBevk-xVwuDECzpzWA=vbJA@mail.gmail.com>
 <20150308203230.GA17183@x60s.casa>
Message-ID: <CAHYVw0yt0YTP-ouOZ7N6s+iguyL8tHZdrsNgmy3ooV_j-adwJg@mail.gmail.com>

sure, my point is that there no universe where we wont HAVE to have an
"otherlicense" option (ie, we MUST always have that escape hatch)

likewise, i dont understand the dual license point. Could you explain a bit
more?

At the end of the day, auditing the licensing/intellectual property status
of ones codebase/dependencies is subtle enough that i'm going to stay
skeptical of any process that doesn't require human thought at the end of
the line. For no other reason than its an insanely complicated topic.

the law is about corner cases, "99%" is not a very good coverage. :)

that said, i'm happy that someone is spending time thinking about this
stuff,  i'm just gonna try to push back on some anything which i think over
reaches or veers into positing a legal opinion :)
cheers!
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150308/f70e070d/attachment.html>

From mietek at bak.io  Sun Mar 15 07:18:47 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Sun, 15 Mar 2015 07:18:47 +0000
Subject: Cabal webpage on haskell.org
Message-ID: <68140263-C9E7-42AB-BE0A-6774DCB537F7@bak.io>

There are at two problems with the Cabal webpage on haskell.org:


1.  The release directories are no longer browseable, as attempting to list their contents fails with 403 errors.

Being able to browse these directories was probably the only way to locate binary downloads for releases older than the one linked from the download page, which is currently 1.22.0.0.

https://www.haskell.org/cabal/release/cabal-install-1.22.0.0/
https://www.haskell.org/cabal/release/cabal-install-1.20.0.3/
https://www.haskell.org/cabal/release/


2.  1.22.0.0 is still listed as the latest version on the download page, even though 1.22.1.0 and 1.22.1.1 were released 3 weeks ago.

https://www.haskell.org/cabal/download.html
https://github.com/haskell/cabal/releases


How can I help get this fixed?


-- 
Mi?tek




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150315/ba112fcb/attachment.bin>

From johan.tibell at gmail.com  Mon Mar 16 07:14:06 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 16 Mar 2015 15:14:06 +0800
Subject: Please review: new wiki page with release instructions
Message-ID: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>

In order to allow other people than me to make releases in the future, I
tried to write down a step-by-step guide to making a release (the page is
linked from the wiki homepage):

https://github.com/haskell/cabal/wiki/Making-a-release

I'd appreciate if people could take a look and see if there's something
missing (e.g. the actual build steps using a sandbox tend to not always
work, asking me to re-configure as the Cabal version changed.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150316/0a8321eb/attachment.html>

From bjp at informatik.uni-kiel.de  Tue Mar 17 09:23:20 2015
From: bjp at informatik.uni-kiel.de (=?windows-1252?Q?Bj=F6rn_Peem=F6ller?=)
Date: Tue, 17 Mar 2015 10:23:20 +0100
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3
In-Reply-To: <CAEs96n04Qx4dMhkvbyJWKfQEuh69PdJKUOLOjTatQ=D_64KarA@mail.gmail.com>
References: <CAEs96n04Qx4dMhkvbyJWKfQEuh69PdJKUOLOjTatQ=D_64KarA@mail.gmail.com>
Message-ID: <5507F288.8030806@informatik.uni-kiel.de>

Am 16.03.2015 um 21:30 schrieb Austin Seipp:
> We are pleased to announce the third release candidate for GHC 7.10.1:
> 
>     https://downloads.haskell.org/~ghc/7.10.1-rc3
>     https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/

The current version of cabal-install located at Hackage can not be
installed for the RC because of the following dependency error:

Setup: At least the following dependencies are missing:
filepath >=1.0 && <1.4

The problem is that cabal-install require filepath < 1.4, while the RC
ships with filepath-1.4. This issue [1] has already been solved in
cabal-install, so a new release available at Hackage would be desirable.

Regards,
Bj?rn

[1]: https://github.com/haskell/cabal/issues/2461

From the.dead.shall.rise at gmail.com  Tue Mar 17 13:47:00 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 17 Mar 2015 14:47:00 +0100
Subject: Please review: new wiki page with release instructions
In-Reply-To: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
References: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
Message-ID: <CA+tcxkAfnLd2JppU0QRf-wJ=mwyGq7p35bLxAE2bj3zO5SwMzQ@mail.gmail.com>

Hi Johan,

On 16 March 2015 at 08:14, Johan Tibell <johan.tibell at gmail.com> wrote:
> [...]
>
> https://github.com/haskell/cabal/wiki/Making-a-release

Looks OK, thanks for doing this.

From ttuegel at gmail.com  Tue Mar 17 15:15:18 2015
From: ttuegel at gmail.com (Thomas Tuegel)
Date: Tue, 17 Mar 2015 10:15:18 -0500
Subject: Please review: new wiki page with release instructions
In-Reply-To: <CA+tcxkAfnLd2JppU0QRf-wJ=mwyGq7p35bLxAE2bj3zO5SwMzQ@mail.gmail.com>
References: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
 <CA+tcxkAfnLd2JppU0QRf-wJ=mwyGq7p35bLxAE2bj3zO5SwMzQ@mail.gmail.com>
Message-ID: <CAHgDWkb2JV08yBgSJ1RHjatFHXovTYs+LhTSC2GRTNpB13519w@mail.gmail.com>

On Tue, Mar 17, 2015 at 8:47 AM, Mikhail Glushenkov
<the.dead.shall.rise at gmail.com> wrote:
> Hi Johan,
>
> On 16 March 2015 at 08:14, Johan Tibell <johan.tibell at gmail.com> wrote:
>> [...]
>>
>> https://github.com/haskell/cabal/wiki/Making-a-release
>
> Looks OK, thanks for doing this.

Thanks for putting that together, Johan!

Is anyone doing new releases for GHC 7.10? cabal-install needs the
filepath dependency bumped, at least. GHC-7.10.1-rc3 is actually
shipping an unreleased version of Cabal, so I think we should release
that ASAP so the final version can be included in ghc-7.10.1. I
volunteer to do these releases, so if one of you has already started,
please speak up! Otherwise, please alert me if you have any blocking
issues; AFAIK there are none at this time.

-- 
Thomas Tuegel

From the.dead.shall.rise at gmail.com  Tue Mar 17 15:29:00 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 17 Mar 2015 16:29:00 +0100
Subject: Please review: new wiki page with release instructions
In-Reply-To: <CAHgDWkb2JV08yBgSJ1RHjatFHXovTYs+LhTSC2GRTNpB13519w@mail.gmail.com>
References: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
 <CA+tcxkAfnLd2JppU0QRf-wJ=mwyGq7p35bLxAE2bj3zO5SwMzQ@mail.gmail.com>
 <CAHgDWkb2JV08yBgSJ1RHjatFHXovTYs+LhTSC2GRTNpB13519w@mail.gmail.com>
Message-ID: <CA+tcxkCbT-fBjr9YstVvcU9Rp9u8Lc7Vo76gKnLvLZ5h-8D5Eg@mail.gmail.com>

Hi,

On 17 March 2015 at 16:15, Thomas Tuegel <ttuegel at gmail.com> wrote:
>
> Otherwise, please alert me if you have any blocking
> issues; AFAIK there are none at this time.

There are two test cases that are failing with 7.10, but fixing them
will probably only require changes to the tests themselves. I'm
looking into this right now.

From hvr at gnu.org  Tue Mar 17 15:30:56 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 17 Mar 2015 16:30:56 +0100
Subject: Please review: new wiki page with release instructions
In-Reply-To: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
 (Johan Tibell's message of "Mon, 16 Mar 2015 15:14:06 +0800")
References: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
Message-ID: <87a8zbljyn.fsf@gnu.org>

On 2015-03-16 at 08:14:06 +0100, Johan Tibell wrote:
> In order to allow other people than me to make releases in the future, I
> tried to write down a step-by-step guide to making a release (the page is
> linked from the wiki homepage):
>
> https://github.com/haskell/cabal/wiki/Making-a-release
>
> I'd appreciate if people could take a look and see if there's something
> missing (e.g. the actual build steps using a sandbox tend to not always
> work, asking me to re-configure as the Cabal version changed.)

regarding

  # Tag the release.
  git tag Cabal-v$(VERSION)

this only creates a lightweight Git tag which are not the recommended
to be used for release-tagging. Moreover, annotated Git tags allow for
(optional) gpg-signing.

So I'd rather suggest to use

  git tag -a -s -m "Cabal $(VERSION)" Cabal-v$(VERSION)

to create annotated Git tags carrying a more of meta-data, including a
GPG signature. Moroever, as a practical motivation beyond giving a bit
more authenticity to the release tags, tooling like git-describe or git
submodule ignore lightweight tags by default.

Cheers,
  hvr

From hesselink at gmail.com  Tue Mar 17 16:14:24 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 17 Mar 2015 17:14:24 +0100
Subject: Please review: new wiki page with release instructions
In-Reply-To: <CA+tcxkCbT-fBjr9YstVvcU9Rp9u8Lc7Vo76gKnLvLZ5h-8D5Eg@mail.gmail.com>
References: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
 <CA+tcxkAfnLd2JppU0QRf-wJ=mwyGq7p35bLxAE2bj3zO5SwMzQ@mail.gmail.com>
 <CAHgDWkb2JV08yBgSJ1RHjatFHXovTYs+LhTSC2GRTNpB13519w@mail.gmail.com>
 <CA+tcxkCbT-fBjr9YstVvcU9Rp9u8Lc7Vo76gKnLvLZ5h-8D5Eg@mail.gmail.com>
Message-ID: <CAPeieQEA8=Z-U5PhR3AdtGV3YR3E-M-HEek55B16tThKQXkbEA@mail.gmail.com>

On Tue, Mar 17, 2015 at 4:29 PM, Mikhail Glushenkov
<the.dead.shall.rise at gmail.com> wrote:
> Hi,
>
> On 17 March 2015 at 16:15, Thomas Tuegel <ttuegel at gmail.com> wrote:
>>
>> Otherwise, please alert me if you have any blocking
>> issues; AFAIK there are none at this time.
>
> There are two test cases that are failing with 7.10, but fixing them
> will probably only require changes to the tests themselves. I'm
> looking into this right now.

It would be great if this regression [1] could be fixed. It is causing
issues with packages with custom Setup.hs files on older GHC releases.
It was fixed before, but broke again.

Erik

[1] https://github.com/haskell/cabal/issues/2409

From johan.tibell at gmail.com  Tue Mar 17 20:43:58 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 18 Mar 2015 04:43:58 +0800
Subject: Please review: new wiki page with release instructions
In-Reply-To: <CAPeieQEA8=Z-U5PhR3AdtGV3YR3E-M-HEek55B16tThKQXkbEA@mail.gmail.com>
References: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
 <CA+tcxkAfnLd2JppU0QRf-wJ=mwyGq7p35bLxAE2bj3zO5SwMzQ@mail.gmail.com>
 <CAHgDWkb2JV08yBgSJ1RHjatFHXovTYs+LhTSC2GRTNpB13519w@mail.gmail.com>
 <CA+tcxkCbT-fBjr9YstVvcU9Rp9u8Lc7Vo76gKnLvLZ5h-8D5Eg@mail.gmail.com>
 <CAPeieQEA8=Z-U5PhR3AdtGV3YR3E-M-HEek55B16tThKQXkbEA@mail.gmail.com>
Message-ID: <CAK-tuPZBo=F7vGtBiJA5GVoPDyCaXEUKDM-1tbrNJwbHTGxKfg@mail.gmail.com>

If someone could let me know when all the needed patches are on the 1.22
branch (and if we need both a Cabal and cabal-install release), I will make
the release and take it as an opportunity to validate the release process
instructions.

P.S. I will try the tagging Herbert suggested.

On Wed, Mar 18, 2015 at 12:14 AM, Erik Hesselink <hesselink at gmail.com>
wrote:

> On Tue, Mar 17, 2015 at 4:29 PM, Mikhail Glushenkov
> <the.dead.shall.rise at gmail.com> wrote:
> > Hi,
> >
> > On 17 March 2015 at 16:15, Thomas Tuegel <ttuegel at gmail.com> wrote:
> >>
> >> Otherwise, please alert me if you have any blocking
> >> issues; AFAIK there are none at this time.
> >
> > There are two test cases that are failing with 7.10, but fixing them
> > will probably only require changes to the tests themselves. I'm
> > looking into this right now.
>
> It would be great if this regression [1] could be fixed. It is causing
> issues with packages with custom Setup.hs files on older GHC releases.
> It was fixed before, but broke again.
>
> Erik
>
> [1] https://github.com/haskell/cabal/issues/2409
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150318/4e979585/attachment.html>

From gershomb at gmail.com  Wed Mar 18 21:55:18 2015
From: gershomb at gmail.com (Gershom B)
Date: Wed, 18 Mar 2015 17:55:18 -0400
Subject: Cabal webpage on haskell.org
In-Reply-To: <68140263-C9E7-42AB-BE0A-6774DCB537F7@bak.io>
References: <68140263-C9E7-42AB-BE0A-6774DCB537F7@bak.io>
Message-ID: <CAM8RHpGRR42Wpx7Yc8yPnaGGj6Lt=gNHWWgK2mLMeCnG5hk9nw@mail.gmail.com>

Mitek: Go ahead and send on a public ssh key to admin@ and we'll get
you access to that portion of the site.

In terms of further contributions / places to start, Johan  mentioned
he would in particular appreciate help in automating this process:
https://github.com/haskell/cabal/wiki/Making-a-release

Sound good?

Cheers,
Gershom

On Sun, Mar 15, 2015 at 3:18 AM, Mi?tek Bak <mietek at bak.io> wrote:
> There are at two problems with the Cabal webpage on haskell.org:
>
>
> 1.  The release directories are no longer browseable, as attempting to list their contents fails with 403 errors.
>
> Being able to browse these directories was probably the only way to locate binary downloads for releases older than the one linked from the download page, which is currently 1.22.0.0.
>
> https://www.haskell.org/cabal/release/cabal-install-1.22.0.0/
> https://www.haskell.org/cabal/release/cabal-install-1.20.0.3/
> https://www.haskell.org/cabal/release/
>
>
> 2.  1.22.0.0 is still listed as the latest version on the download page, even though 1.22.1.0 and 1.22.1.1 were released 3 weeks ago.
>
> https://www.haskell.org/cabal/download.html
> https://github.com/haskell/cabal/releases
>
>
> How can I help get this fixed?
>
>
> --
> Mi?tek
>
>
>
>

From the.dead.shall.rise at gmail.com  Wed Mar 18 22:57:01 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Wed, 18 Mar 2015 23:57:01 +0100
Subject: Cabal webpage on haskell.org
In-Reply-To: <CAM8RHpGRR42Wpx7Yc8yPnaGGj6Lt=gNHWWgK2mLMeCnG5hk9nw@mail.gmail.com>
References: <68140263-C9E7-42AB-BE0A-6774DCB537F7@bak.io>
 <CAM8RHpGRR42Wpx7Yc8yPnaGGj6Lt=gNHWWgK2mLMeCnG5hk9nw@mail.gmail.com>
Message-ID: <CA+tcxkCdZz=BOH0GcbJyGAczR9P_7wAmqnBaZcHY=pqiEo6JHw@mail.gmail.com>

Hi,

On 18 March 2015 at 22:55, Gershom B <gershomb at gmail.com> wrote:
> Mitek: Go ahead and send on a public ssh key to admin@ and we'll get
> you access to that portion of the site.

A better idea is to upload the website's source files to GitHub and
let people send us pull requests there. I can do that if someone gives
me ssh access.

From the.dead.shall.rise at gmail.com  Thu Mar 19 15:48:05 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 19 Mar 2015 16:48:05 +0100
Subject: Please review: new wiki page with release instructions
In-Reply-To: <CAK-tuPZBo=F7vGtBiJA5GVoPDyCaXEUKDM-1tbrNJwbHTGxKfg@mail.gmail.com>
References: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
 <CA+tcxkAfnLd2JppU0QRf-wJ=mwyGq7p35bLxAE2bj3zO5SwMzQ@mail.gmail.com>
 <CAHgDWkb2JV08yBgSJ1RHjatFHXovTYs+LhTSC2GRTNpB13519w@mail.gmail.com>
 <CA+tcxkCbT-fBjr9YstVvcU9Rp9u8Lc7Vo76gKnLvLZ5h-8D5Eg@mail.gmail.com>
 <CAPeieQEA8=Z-U5PhR3AdtGV3YR3E-M-HEek55B16tThKQXkbEA@mail.gmail.com>
 <CAK-tuPZBo=F7vGtBiJA5GVoPDyCaXEUKDM-1tbrNJwbHTGxKfg@mail.gmail.com>
Message-ID: <CA+tcxkAdMtiAFiPKK4p2Roba6DbCk5b9gaXbVynL1vk8BQwBNw@mail.gmail.com>

Hi,

On 17 March 2015 at 21:43, Johan Tibell <johan.tibell at gmail.com> wrote:
> If someone could let me know when all the needed patches are on the 1.22
> branch (and if we need both a Cabal and cabal-install release), I will make
> the release and take it as an opportunity to validate the release process
> instructions.

I believe I have now fixed all the remaining issues on the 1.22 branch
and we're ready for a new point release.

Herbert, can you please update GHC 7.10 Cabal submodule reference to
the tip of the 1.22 branch?

From johan.tibell at gmail.com  Thu Mar 19 16:48:14 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 19 Mar 2015 17:48:14 +0100
Subject: Please review: new wiki page with release instructions
In-Reply-To: <87y4mt3pfd.fsf@gmail.com>
References: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
 <CA+tcxkAfnLd2JppU0QRf-wJ=mwyGq7p35bLxAE2bj3zO5SwMzQ@mail.gmail.com>
 <CAHgDWkb2JV08yBgSJ1RHjatFHXovTYs+LhTSC2GRTNpB13519w@mail.gmail.com>
 <CA+tcxkCbT-fBjr9YstVvcU9Rp9u8Lc7Vo76gKnLvLZ5h-8D5Eg@mail.gmail.com>
 <CAPeieQEA8=Z-U5PhR3AdtGV3YR3E-M-HEek55B16tThKQXkbEA@mail.gmail.com>
 <CAK-tuPZBo=F7vGtBiJA5GVoPDyCaXEUKDM-1tbrNJwbHTGxKfg@mail.gmail.com>
 <CA+tcxkAdMtiAFiPKK4p2Roba6DbCk5b9gaXbVynL1vk8BQwBNw@mail.gmail.com>
 <87y4mt3pfd.fsf@gmail.com>
Message-ID: <CAK-tuPYS7EaDFvWOTzr+Mz+Q23At7W-ZxFv4jQW=a6WOaeMtUw@mail.gmail.com>

Ryan (CCed) will try out the Cabal/cabal-install release flow tonight, with
my help.

On Thu, Mar 19, 2015 at 5:47 PM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> On 2015-03-19 at 16:48:05 +0100, Mikhail Glushenkov wrote:
>
> [...]
>
> > I believe I have now fixed all the remaining issues on the 1.22 branch
> > and we're ready for a new point release.
> >
> > Herbert, can you please update GHC 7.10 Cabal submodule reference to
> > the tip of the 1.22 branch?
>
> done (and it still validates):
>
>
> http://git.haskell.org/ghc.git/commitdiff/7c132c02436fadaa70674bbfe38b21a67c4fed3a
>
> Cheers,
>   hvr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150319/35a68c9c/attachment.html>

From the.dead.shall.rise at gmail.com  Thu Mar 19 17:00:27 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 19 Mar 2015 18:00:27 +0100
Subject: Please review: new wiki page with release instructions
In-Reply-To: <87y4mt3pfd.fsf@gmail.com>
References: <CAK-tuPZs0QvZhoCdtErTYLCTd6cPdzCMSsJZjHDCdcOzyU8xWg@mail.gmail.com>
 <CA+tcxkAfnLd2JppU0QRf-wJ=mwyGq7p35bLxAE2bj3zO5SwMzQ@mail.gmail.com>
 <CAHgDWkb2JV08yBgSJ1RHjatFHXovTYs+LhTSC2GRTNpB13519w@mail.gmail.com>
 <CA+tcxkCbT-fBjr9YstVvcU9Rp9u8Lc7Vo76gKnLvLZ5h-8D5Eg@mail.gmail.com>
 <CAPeieQEA8=Z-U5PhR3AdtGV3YR3E-M-HEek55B16tThKQXkbEA@mail.gmail.com>
 <CAK-tuPZBo=F7vGtBiJA5GVoPDyCaXEUKDM-1tbrNJwbHTGxKfg@mail.gmail.com>
 <CA+tcxkAdMtiAFiPKK4p2Roba6DbCk5b9gaXbVynL1vk8BQwBNw@mail.gmail.com>
 <87y4mt3pfd.fsf@gmail.com>
Message-ID: <CA+tcxkBXz7s-p6f=Fzsp9QxaSShz8384mw=qxHGeS2YKHciKoA@mail.gmail.com>

Hi,

On 19 March 2015 at 17:47, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> done (and it still validates):
>
>   http://git.haskell.org/ghc.git/commitdiff/7c132c02436fadaa70674bbfe38b21a67c4fed3a

Great, thanks!

From johan.tibell at gmail.com  Sat Mar 21 09:17:48 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 21 Mar 2015 10:17:48 +0100
Subject: Ryan Thomas is the new release manager
Message-ID: <CAK-tuPaK07v858BkGK6Gha7ydEgK6L2wD3Ru341byyhrA9CdeQ@mail.gmail.com>

Hi everyone,

I haven't had the time recently to give cabal release process the it
deserves, so I'm happy to announce that Ryan Thomas (CCed) has agreed to
take over the release manager responsibility.

Ryan has already made a minor Cabal release, to accompany the imminent GHC
7.10 release. He will look into making a cabal-install release shortly.

P.S. Other people also expressed interest in helping out. That's great!
Cabal is definitely not suffering from having too many contributors. If a
couple of you would like to put your heads together (and, dare I say, form
a release Cabal) and improve the release process, I think that would be a
great thing.

P.S.S. I will still be around, just trying to step away from the day to day
work a little bit.

-- Johan Tibell, ex-release manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150321/00d8f3c2/attachment.html>

From the.dead.shall.rise at gmail.com  Sat Mar 21 20:47:36 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sat, 21 Mar 2015 21:47:36 +0100
Subject: Ryan Thomas is the new release manager
In-Reply-To: <CAK-tuPaK07v858BkGK6Gha7ydEgK6L2wD3Ru341byyhrA9CdeQ@mail.gmail.com>
References: <CAK-tuPaK07v858BkGK6Gha7ydEgK6L2wD3Ru341byyhrA9CdeQ@mail.gmail.com>
Message-ID: <CA+tcxkCbKjGNCwtCYgpqywA+0PTXaMi2D_yCS43sVFazi65HxQ@mail.gmail.com>

Welcome onboard Ryan!

On 21 March 2015 at 10:17, Johan Tibell <johan.tibell at gmail.com> wrote:
> Hi everyone,
>
> I haven't had the time recently to give cabal release process the it
> deserves, so I'm happy to announce that Ryan Thomas (CCed) has agreed to
> take over the release manager responsibility.
>
> [...]

From ryan at ryant.org  Sat Mar 21 21:29:48 2015
From: ryan at ryant.org (Ryan Thomas)
Date: Sat, 21 Mar 2015 21:29:48 +0000
Subject: Ryan Thomas is the new release manager
In-Reply-To: <CA+tcxkCbKjGNCwtCYgpqywA+0PTXaMi2D_yCS43sVFazi65HxQ@mail.gmail.com>
References: <CAK-tuPaK07v858BkGK6Gha7ydEgK6L2wD3Ru341byyhrA9CdeQ@mail.gmail.com>
 <CA+tcxkCbKjGNCwtCYgpqywA+0PTXaMi2D_yCS43sVFazi65HxQ@mail.gmail.com>
Message-ID: <CAJCpNroXBsfg45WBeSVyt133Ob30Nw6iCkCKq_RDRkpe6jWNgg@mail.gmail.com>

Thanks guys!

On 21 March 2015 at 20:47, Mikhail Glushenkov
<the.dead.shall.rise at gmail.com> wrote:
> Welcome onboard Ryan!
>
> On 21 March 2015 at 10:17, Johan Tibell <johan.tibell at gmail.com> wrote:
>> Hi everyone,
>>
>> I haven't had the time recently to give cabal release process the it
>> deserves, so I'm happy to announce that Ryan Thomas (CCed) has agreed to
>> take over the release manager responsibility.
>>
>> [...]

From ryan at ryant.org  Sat Mar 21 21:34:28 2015
From: ryan at ryant.org (Ryan Thomas)
Date: Sat, 21 Mar 2015 21:34:28 +0000
Subject: Cabal and cabal-install minor release (1.22.2.0)
Message-ID: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>

I have released both Cabal and cabal-install 1.22.2.0 today,
cabal-install has just gone out now.

These have been published to Hackage and are available on the download
page of haskell.org.

As a part of this process I have also updated the release
documentation (https://github.com/haskell/cabal/wiki/Making-a-release)
to support the new sftp-only push to haskell.org.

There are a couple of outstanding items to tie off with this release:
- The {Cabal|cabal-install}-latest symlinks on haskell.org still need
to be updated
- The Windows/OSX/Linux specific binaries need to be built and updated
on the download page; Johan I will probably need some guidance on the
process for this.

Once I get these items tied off, my main focus will be the automation
of this release process.


Cheers,

ryan

From the.dead.shall.rise at gmail.com  Sat Mar 21 22:30:33 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sat, 21 Mar 2015 23:30:33 +0100
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
Message-ID: <CA+tcxkBAggiHZWgAX6kvgH=UAgsVh=_jJP+QbcKUXq=viYcY7Q@mail.gmail.com>

Hi,

On 21 March 2015 at 22:34, Ryan Thomas <ryan at ryant.org> wrote:
> There are a couple of outstanding items to tie off with this release:
> - The Windows/OSX/Linux specific binaries need to be built and updated
> on the download page; Johan I will probably need some guidance on the
> process for this.

I can build Windows/Linux binaries, but someone with access to
haskell.org/cabal will have to upload them. I asked admin at haskell.org
to give me upload access, but haven't received a reply yet.

From ryan at ryant.org  Sat Mar 21 23:01:25 2015
From: ryan at ryant.org (Ryan Thomas)
Date: Sat, 21 Mar 2015 23:01:25 +0000
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <CA+tcxkBAggiHZWgAX6kvgH=UAgsVh=_jJP+QbcKUXq=viYcY7Q@mail.gmail.com>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
 <CA+tcxkBAggiHZWgAX6kvgH=UAgsVh=_jJP+QbcKUXq=viYcY7Q@mail.gmail.com>
Message-ID: <CAJCpNrodR5c4Rhsp57nnY-H9G8mUPkdst9JNSya-zxFak25EFw@mail.gmail.com>

Hey Mikhail, I can upload them if you can send them to me.

On 21 March 2015 at 22:30, Mikhail Glushenkov
<the.dead.shall.rise at gmail.com> wrote:
> Hi,
>
> On 21 March 2015 at 22:34, Ryan Thomas <ryan at ryant.org> wrote:
>> There are a couple of outstanding items to tie off with this release:
>> - The Windows/OSX/Linux specific binaries need to be built and updated
>> on the download page; Johan I will probably need some guidance on the
>> process for this.
>
> I can build Windows/Linux binaries, but someone with access to
> haskell.org/cabal will have to upload them. I asked admin at haskell.org
> to give me upload access, but haven't received a reply yet.

From mietek at bak.io  Sat Mar 21 23:49:58 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Sat, 21 Mar 2015 23:49:58 +0000
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
Message-ID: <A7DDA2A0-8ECD-4B79-93A8-3AFC7985EA68@bak.io>

Thanks, Ryan.


Binaries of cabal-install 1.22.2.0 are now available in Halcyon on the following platforms:

- Amazon Linux 2014.09 (x86_64)
- Arch Linux (x86_64)
- CentOS 6 (i386 and x86_64)
- CentOS 7 (x86_64)
- Debian 6 (i386 and x86_64)
- Debian 7 (i386 and x86_64)
- Fedora 19 (i386 and x86_64)
- Fedora 20 (i386 and x86_64)
- Fedora 21 (x86_64)
- openSUSE 13.2 (x86_64)
- OS X 10.8 (x86_64)
- OS X 10.9 (x86_64)
- OS X 10.10 (x86_64)
- Red Hat Enterprise Linux 6 (x86_64)
- Red Hat Enterprise Linux 7 (x86_64)
- SUSE Linux Enterprise Server 12 (x86_64)
- Ubuntu 10.04 LTS (i386 and x86_64)
- Ubuntu 12.04 LTS (i386 and x86_64)
- Ubuntu 14.04 LTS (i386 and x86_64)
- Ubuntu 14.10 (i386 and x86_64)

See https://github.com/mietek/halcyon/issues/38 for details of cross-platform support.


Let me know if I can help with the automation.


-- 
Mi?tek




On 2015-03-21, at 21:34, Ryan Thomas <ryan at ryant.org> wrote:

> I have released both Cabal and cabal-install 1.22.2.0 today,
> cabal-install has just gone out now.
> 
> These have been published to Hackage and are available on the download
> page of haskell.org.
> 
> As a part of this process I have also updated the release
> documentation (https://github.com/haskell/cabal/wiki/Making-a-release)
> to support the new sftp-only push to haskell.org.
> 
> There are a couple of outstanding items to tie off with this release:
> - The {Cabal|cabal-install}-latest symlinks on haskell.org still need
> to be updated
> - The Windows/OSX/Linux specific binaries need to be built and updated
> on the download page; Johan I will probably need some guidance on the
> process for this.
> 
> Once I get these items tied off, my main focus will be the automation
> of this release process.
> 
> 
> Cheers,
> 
> ryan
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150321/4c3358d2/attachment.bin>

From johan.tibell at gmail.com  Sun Mar 22 08:19:53 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun, 22 Mar 2015 09:19:53 +0100
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
Message-ID: <CAK-tuPaay7R+6qJ1k8cNv1m-ZQOEVyL2mDabTCBDhyRRYntifA@mail.gmail.com>

On Sat, Mar 21, 2015 at 10:34 PM, Ryan Thomas <ryan at ryant.org> wrote:

> - The Windows/OSX/Linux specific binaries need to be built and updated
> on the download page; Johan I will probably need some guidance on the
> process for this.
>

There's not much of a process I'm afraid. I usually send out and email to
cabal-devel@, asking for people to build binaries and send them to me. I
build some myself. Ideally at least one binary would be built by the
release process itself (and the others perhaps by build bots).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150322/fbff91e6/attachment.html>

From lambda.fairy at gmail.com  Sun Mar 22 08:36:46 2015
From: lambda.fairy at gmail.com (Chris Wong)
Date: Sun, 22 Mar 2015 21:36:46 +1300
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <CAK-tuPaay7R+6qJ1k8cNv1m-ZQOEVyL2mDabTCBDhyRRYntifA@mail.gmail.com>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
 <CAK-tuPaay7R+6qJ1k8cNv1m-ZQOEVyL2mDabTCBDhyRRYntifA@mail.gmail.com>
Message-ID: <CANQO64LQfQFtYkX5yP9v02fOKawFrr9NKxF-gsK5UqXsjaEzLw@mail.gmail.com>

On Sun, Mar 22, 2015 at 9:19 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Sat, Mar 21, 2015 at 10:34 PM, Ryan Thomas <ryan at ryant.org> wrote:
>>
>> - The Windows/OSX/Linux specific binaries need to be built and updated
>> on the download page; Johan I will probably need some guidance on the
>> process for this.
>
>
> There's not much of a process I'm afraid. I usually send out and email to
> cabal-devel@, asking for people to build binaries and send them to me. I
> build some myself. Ideally at least one binary would be built by the release
> process itself (and the others perhaps by build bots).

AppVeyor and Travis CI support Windows and OS X respectively; perhaps
we can arrange something with those.

> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>

-- 
https://lambda.xyz

From ryan at ryant.org  Sun Mar 22 08:38:25 2015
From: ryan at ryant.org (Ryan Thomas)
Date: Sun, 22 Mar 2015 08:38:25 +0000
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <CANQO64LQfQFtYkX5yP9v02fOKawFrr9NKxF-gsK5UqXsjaEzLw@mail.gmail.com>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
 <CAK-tuPaay7R+6qJ1k8cNv1m-ZQOEVyL2mDabTCBDhyRRYntifA@mail.gmail.com>
 <CANQO64LQfQFtYkX5yP9v02fOKawFrr9NKxF-gsK5UqXsjaEzLw@mail.gmail.com>
Message-ID: <CAJCpNrp3eNkwCvx4vG_KSe2QbmQpapCiPVzCZPHnnWd1+Xq3UA@mail.gmail.com>

Agreed, I'd love to have the CI tools build all of the release artifacts.

Mi?tek: I'll update the downloads page with a link to halcyon for
those platforms.

Cheers,

ryan

On 22 March 2015 at 08:36, Chris Wong <lambda.fairy at gmail.com> wrote:
> On Sun, Mar 22, 2015 at 9:19 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>> On Sat, Mar 21, 2015 at 10:34 PM, Ryan Thomas <ryan at ryant.org> wrote:
>>>
>>> - The Windows/OSX/Linux specific binaries need to be built and updated
>>> on the download page; Johan I will probably need some guidance on the
>>> process for this.
>>
>>
>> There's not much of a process I'm afraid. I usually send out and email to
>> cabal-devel@, asking for people to build binaries and send them to me. I
>> build some myself. Ideally at least one binary would be built by the release
>> process itself (and the others perhaps by build bots).
>
> AppVeyor and Travis CI support Windows and OS X respectively; perhaps
> we can arrange something with those.
>
>> _______________________________________________
>> cabal-devel mailing list
>> cabal-devel at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>>
>
> --
> https://lambda.xyz

From the.dead.shall.rise at gmail.com  Mon Mar 23 00:35:09 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 23 Mar 2015 01:35:09 +0100
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <A7DDA2A0-8ECD-4B79-93A8-3AFC7985EA68@bak.io>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
 <A7DDA2A0-8ECD-4B79-93A8-3AFC7985EA68@bak.io>
Message-ID: <CA+tcxkBdMk4UPSwjDKFQ_K_D8LsoR+sLwEZpubrq4bYGPE5TsQ@mail.gmail.com>

Hi,

On 22 March 2015 at 00:49, Mi?tek Bak <mietek at bak.io> wrote:
> Thanks, Ryan.
>
>
> Binaries of cabal-install 1.22.2.0 are now available in Halcyon on the following platforms:
>
> [...]

That's quite impressive! Have you considered adding Windows support?
Our release process could use some automation in this area.

From mietek at bak.io  Mon Mar 23 00:58:11 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Mon, 23 Mar 2015 00:58:11 +0000
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <CAJCpNrp3eNkwCvx4vG_KSe2QbmQpapCiPVzCZPHnnWd1+Xq3UA@mail.gmail.com>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
 <CAK-tuPaay7R+6qJ1k8cNv1m-ZQOEVyL2mDabTCBDhyRRYntifA@mail.gmail.com>
 <CANQO64LQfQFtYkX5yP9v02fOKawFrr9NKxF-gsK5UqXsjaEzLw@mail.gmail.com>
 <CAJCpNrp3eNkwCvx4vG_KSe2QbmQpapCiPVzCZPHnnWd1+Xq3UA@mail.gmail.com>
Message-ID: <0754B7EF-BA0E-4802-9906-203BA5594281@bak.io>

Thanks, Ryan.  I?ve since added binaries of 1.22.2.0 for:

- Gentoo Linux (x86_64)
- Slackware 14.1 (x86_64)

I should note this is in addition to binaries of 1.22.0.0 and 1.20.0.3, also available for all of the previously mentioned platforms.

Other versions can also be selected by the user to be bootstrapped and automatically cached:
https://halcyon.sh/reference/#halcyon_cabal_version


-- 
Mi?tek
https://mietek.io




On 2015-03-22, at 08:38, Ryan Thomas <ryan at ryant.org> wrote:

> Agreed, I'd love to have the CI tools build all of the release artifacts.
> 
> Mi?tek: I'll update the downloads page with a link to halcyon for
> those platforms.
> 
> Cheers,
> 
> ryan
> 
> On 22 March 2015 at 08:36, Chris Wong <lambda.fairy at gmail.com> wrote:
>> On Sun, Mar 22, 2015 at 9:19 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>>> On Sat, Mar 21, 2015 at 10:34 PM, Ryan Thomas <ryan at ryant.org> wrote:
>>>> 
>>>> - The Windows/OSX/Linux specific binaries need to be built and updated
>>>> on the download page; Johan I will probably need some guidance on the
>>>> process for this.
>>> 
>>> 
>>> There's not much of a process I'm afraid. I usually send out and email to
>>> cabal-devel@, asking for people to build binaries and send them to me. I
>>> build some myself. Ideally at least one binary would be built by the release
>>> process itself (and the others perhaps by build bots).
>> 
>> AppVeyor and Travis CI support Windows and OS X respectively; perhaps
>> we can arrange something with those.
>> 
>>> _______________________________________________
>>> cabal-devel mailing list
>>> cabal-devel at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>>> 
>> 
>> --
>> https://lambda.xyz
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/6c89416e/attachment.bin>

From mietek at bak.io  Mon Mar 23 01:42:38 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Mon, 23 Mar 2015 01:42:38 +0000
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <CA+tcxkBdMk4UPSwjDKFQ_K_D8LsoR+sLwEZpubrq4bYGPE5TsQ@mail.gmail.com>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
 <A7DDA2A0-8ECD-4B79-93A8-3AFC7985EA68@bak.io>
 <CA+tcxkBdMk4UPSwjDKFQ_K_D8LsoR+sLwEZpubrq4bYGPE5TsQ@mail.gmail.com>
Message-ID: <02E88F78-98DD-4825-AD3E-C0C8B9060041@bak.io>

I?d like to add Windows support, eventually (https://github.com/mietek/halcyon/issues/42).

My main focus right now is enabling the distribution of Haskell applications in binary form, without requiring the cooperation of application authors.  To be specific, I?d like the user to be able to say `halcyon install idris`, and get the latest version of Idris installed on their system in 5-10 seconds.

Preposterous?  This is how Halcyon already works:
https://halcyon.sh/tutorial/#install-the-app

Of course, this requires the application to be built ahead of time, which in turn requires version constraints to be declared for the application.

Now, application authors don?t seem eager to declare version constraints.  However, declaring a particular version of Stackage LTS is equivalent to declaring a full set of version constraints (https://github.com/mietek/halcyon/issues/41, https://github.com/mietek/halcyon/issues/40).

It seems to me that adopting Stackage LTS should reduce the binary distribution problem to automating the process of performing regular builds across many platforms.

Looking forward to your comments.


-- 
Mi?tek
https://mietek.io




On 2015-03-23, at 00:35, Mikhail Glushenkov <the.dead.shall.rise at gmail.com> wrote:

> Hi,
> 
> On 22 March 2015 at 00:49, Mi?tek Bak <mietek at bak.io> wrote:
>> Thanks, Ryan.
>> 
>> 
>> Binaries of cabal-install 1.22.2.0 are now available in Halcyon on the following platforms:
>> 
>> [...]
> 
> That's quite impressive! Have you considered adding Windows support?
> Our release process could use some automation in this area.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/05a41d69/attachment.bin>

From gershomb at gmail.com  Mon Mar 23 05:46:42 2015
From: gershomb at gmail.com (Gershom B)
Date: Mon, 23 Mar 2015 01:46:42 -0400
Subject: Cabal webpage on haskell.org
In-Reply-To: <68140263-C9E7-42AB-BE0A-6774DCB537F7@bak.io>
References: <68140263-C9E7-42AB-BE0A-6774DCB537F7@bak.io>
Message-ID: <etPan.550fa8d1.507ed7ab.7ed7@mbp.local>

I?ve re-enabled the directory listings for?https://www.haskell.org/cabal/release/

(admins, note: I just changed the nginx.conf directly, we need to backport all our changes into the full deploy scripts?)

?Gershom

On March 15, 2015 at 3:18:52 AM, Mi?tek Bak (mietek at bak.io) wrote:
> There are at two problems with the Cabal webpage on haskell.org:
>  
>  
> 1. The release directories are no longer browseable, as attempting to list their contents  
> fails with 403 errors.
>  
> Being able to browse these directories was probably the only way to locate binary downloads  
> for releases older than the one linked from the download page, which is currently 1.22.0.0.  
>  
> https://www.haskell.org/cabal/release/cabal-install-1.22.0.0/
> https://www.haskell.org/cabal/release/cabal-install-1.20.0.3/
> https://www.haskell.org/cabal/release/
>  
>  
> 2. 1.22.0.0 is still listed as the latest version on the download page, even though 1.22.1.0  
> and 1.22.1.1 were released 3 weeks ago.
>  
> https://www.haskell.org/cabal/download.html
> https://github.com/haskell/cabal/releases
>  
>  
> How can I help get this fixed?
>  
>  
> --
> Mi?tek
>  
>  
>  
>  
>  


From simonpj at microsoft.com  Mon Mar 23 08:45:48 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Mar 2015 08:45:48 +0000
Subject: Cabal and simultaneous installations of the same package
Message-ID: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>

Dear Cabal developers

You'll probably have seen the thread about the Haskell Platform.

Among other things, this point arose:

|  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.

People mean different things by "cabal hell", but the inability to 
	simultaneously install multiple versions of the same package,
	compiled against different dependencies
is certainly one of them, and I think it is the one that Yitzchak is referring to here.

But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously.  So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow.

But time has passed and it hasn't happened. Is this because I'm misunderstanding?  Or because it is harder than I think?  Or because there are much bigger problems?  Or because there is insufficient effort available?  Or what?

Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp.  What's stopping us grasping it?

Simon


From michael at snoyman.com  Mon Mar 23 08:52:31 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 23 Mar 2015 08:52:31 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAKA2JgLazjiJ=SA7nPMgH84+ER-YMXJcvWvAErzJvi-ByLBmQw@mail.gmail.com>

I'm in favor of adding support to Cabal to allow for this situation.
However: I highly doubt this will be the panacea as predicted. It's already
a huge source of confusion for people using GHCi what they get messages
about "ByteString is not ByteString." In fact, this confusion is so
prevalent that I wrote a blog post about it in September[1].

I strongly believe that the best end-user experience comes from having a
single mapping from package name to actually installed
package/version/dependencies. I'd go even farther and say that users would
be well served by having a single mapping from module name to installed
module. In fact, Adam Bergmark even created an issue[2] to look into adding
support to Stackage to start enforcing this situation, though the response
to a blog post I wrote on that[3] implies that people are not so interested
in addressing that problem.

So my word of warning here is: if we simply throw multiple
package/version/dependency combinations at users via cabal, there's a good
chance that we'll do more harm than good.

[1] http://www.yesodweb.com/blog/2014/09/woes-multiple-package-versions
[2] https://github.com/fpco/stackage/issues/416
[3] http://www.yesodweb.com/blog/2014/02/module-name-conflicts

On Mon, Mar 23, 2015 at 10:45 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Dear Cabal developers
>
> You'll probably have seen the thread about the Haskell Platform.
>
> Among other things, this point arose:
>
> |  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.
>
> People mean different things by "cabal hell", but the inability to
>         simultaneously install multiple versions of the same package,
>         compiled against different dependencies
> is certainly one of them, and I think it is the one that Yitzchak is
> referring to here.
>
> But some time now GHC has allowed multiple versions of the same package
> (compiled against different dependencies) to be installed simultaneously.
> So all we need to do is to fix Cabal to allow it too, and thereby kill of a
> huge class of cabal-hell problems at one blow.
>
> But time has passed and it hasn't happened. Is this because I'm
> misunderstanding?  Or because it is harder than I think?  Or because there
> are much bigger problems?  Or because there is insufficient effort
> available?  Or what?
>
> Unless I'm way off beam, this "multiple installations of the same package"
> thing has been a huge pain forever, and the solution is within our grasp.
> What's stopping us grasping it?
>
> Simon
>
> _______________________________________________
> 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/cabal-devel/attachments/20150323/af120e2e/attachment.html>

From ryan at ryant.org  Mon Mar 23 08:57:52 2015
From: ryan at ryant.org (Ryan Thomas)
Date: Mon, 23 Mar 2015 08:57:52 +0000
Subject: Cabal webpage on haskell.org
In-Reply-To: <etPan.550fa8d1.507ed7ab.7ed7@mbp.local>
References: <68140263-C9E7-42AB-BE0A-6774DCB537F7@bak.io>
 <etPan.550fa8d1.507ed7ab.7ed7@mbp.local>
Message-ID: <CAJCpNrrkyaMwGd-FH7=OxhnFFdvDqQBwZ0gty_LF8DjVJ+-Pew@mail.gmail.com>

1.22.2.0 has been updated on the downloads page. The issue still
remains the the '-latest' symlinks have not been updated.

On 23 March 2015 at 05:46, Gershom B <gershomb at gmail.com> wrote:
> I?ve re-enabled the directory listings for https://www.haskell.org/cabal/release/
>
> (admins, note: I just changed the nginx.conf directly, we need to backport all our changes into the full deploy scripts?)
>
> ?Gershom
>
> On March 15, 2015 at 3:18:52 AM, Mi?tek Bak (mietek at bak.io) wrote:
>> There are at two problems with the Cabal webpage on haskell.org:
>>
>>
>> 1. The release directories are no longer browseable, as attempting to list their contents
>> fails with 403 errors.
>>
>> Being able to browse these directories was probably the only way to locate binary downloads
>> for releases older than the one linked from the download page, which is currently 1.22.0.0.
>>
>> https://www.haskell.org/cabal/release/cabal-install-1.22.0.0/
>> https://www.haskell.org/cabal/release/cabal-install-1.20.0.3/
>> https://www.haskell.org/cabal/release/
>>
>>
>> 2. 1.22.0.0 is still listed as the latest version on the download page, even though 1.22.1.0
>> and 1.22.1.1 were released 3 weeks ago.
>>
>> https://www.haskell.org/cabal/download.html
>> https://github.com/haskell/cabal/releases
>>
>>
>> How can I help get this fixed?
>>
>>
>> --
>> Mi?tek
>>
>>
>>
>>
>>
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

From simonpj at microsoft.com  Mon Mar 23 09:52:55 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Mar 2015 09:52:55 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <CAKA2JgLazjiJ=SA7nPMgH84+ER-YMXJcvWvAErzJvi-ByLBmQw@mail.gmail.com>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
 <CAKA2JgLazjiJ=SA7nPMgH84+ER-YMXJcvWvAErzJvi-ByLBmQw@mail.gmail.com>
Message-ID: <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net>

It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString."

Reading your blog post [1] it seems that we are addressing different questions:

?         My proposal is only that the act of *installing* a package does not break existing installed package, and is not rejected because it risks doing so.

?         You agree that the confusing behaviour you describe can?t happen with Cabal.  In any one build, Cabal can ensure that only one version of each package is used in the build, so such a message could never show up.

?         What you want is for the confusing behaviour to be true of GHCi too.  Well that?s simple enough: ensure that the set of exposed packages (ie the ones you say ?import M? for), is consistent in the same way.  The point is that I may need to install a bunch of packages to build a program.  If I?m using Cabal, none of those newly installed packages need be exposed; I simply need them there so I can compile my program (using Cabal).   But at the moment I can?t do that.

That leaves open the following question. Suppose

?         I want to install and expose package P and Q

?         But alas, P depends on containers 2.9 and Q depends on containers 3.1
Now I?m stuck. But there is a good reason for being stuck, and one that is explicable.

Simon


From: Michael Snoyman [mailto:michael at snoyman.com]
Sent: 23 March 2015 08:53
To: Simon Peyton Jones; cabal-devel at haskell.org
Cc: haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org
Subject: Re: Cabal and simultaneous installations of the same package

I'm in favor of adding support to Cabal to allow for this situation. However: I highly doubt this will be the panacea as predicted. It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." In fact, this confusion is so prevalent that I wrote a blog post about it in September[1].

I strongly believe that the best end-user experience comes from having a single mapping from package name to actually installed package/version/dependencies. I'd go even farther and say that users would be well served by having a single mapping from module name to installed module. In fact, Adam Bergmark even created an issue[2] to look into adding support to Stackage to start enforcing this situation, though the response to a blog post I wrote on that[3] implies that people are not so interested in addressing that problem.

So my word of warning here is: if we simply throw multiple package/version/dependency combinations at users via cabal, there's a good chance that we'll do more harm than good.

[1] http://www.yesodweb.com/blog/2014/09/woes-multiple-package-versions
[2] https://github.com/fpco/stackage/issues/416
[3] http://www.yesodweb.com/blog/2014/02/module-name-conflicts

On Mon, Mar 23, 2015 at 10:45 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Dear Cabal developers

You'll probably have seen the thread about the Haskell Platform.

Among other things, this point arose:

|  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.

People mean different things by "cabal hell", but the inability to
        simultaneously install multiple versions of the same package,
        compiled against different dependencies
is certainly one of them, and I think it is the one that Yitzchak is referring to here.

But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously.  So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow.

But time has passed and it hasn't happened. Is this because I'm misunderstanding?  Or because it is harder than I think?  Or because there are much bigger problems?  Or because there is insufficient effort available?  Or what?

Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp.  What's stopping us grasping it?

Simon

_______________________________________________
Libraries mailing list
Libraries at haskell.org<mailto: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/cabal-devel/attachments/20150323/a22644ad/attachment-0001.html>

From michael at snoyman.com  Mon Mar 23 09:58:29 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 23 Mar 2015 09:58:29 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
 <CAKA2JgLazjiJ=SA7nPMgH84+ER-YMXJcvWvAErzJvi-ByLBmQw@mail.gmail.com>
 <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAKA2JgKhM5skNTNGYZVYc+1r70805X6k2hNg=d+SbDm56AxMYA@mail.gmail.com>

On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> It's already a huge source of confusion for people using GHCi what they
> get messages about "ByteString is not ByteString."
>
>
>
> Reading your blog post [1] it seems that we are addressing different
> questions:
>
> ?         My proposal is only that the act of **installing** a package
> does not break existing installed package, and is not rejected because it
> risks doing so.
>
Thank you for the clarification, I had misread that. On that front: I
agree.

>  ?         You agree that the confusing behaviour you describe can?t
> happen with Cabal.  In any one build, Cabal can ensure that only one
> version of each package is used in the build, so such a message could never
> show up.
>
I've seen people discussing exactly such a change to Cabal's behavior, so I
mistakenly took your comments to be heading in that direction. While I
think there *might* be some future where we could expose that
functionality, it could be incredibly confusing. I'd feel much better
starting off with simply the act of installing.

>  ?         What you want is for the confusing behaviour to be true of
> GHCi too.  Well that?s simple enough: ensure that the set of *exposed*
> packages (ie the ones you say ?import M? for), is consistent in the same
> way.  The point is that I may need to install a bunch of packages to build
> a program.  If I?m using Cabal, none of those newly installed packages need
> be exposed; I simply need them there so I can compile my program (using
> Cabal).   But at the moment I can?t do that.
>
>
>
> That leaves open the following question. Suppose
>
> ?         I want to install *and expose* package P and Q
>
> ?         But alas, P depends on containers 2.9 and Q depends on
> containers 3.1
>
> Now I?m stuck. But there is a good reason for being stuck, and one that is
> explicable.
>
>
>

If I'm reading this correctly, the proposal then would be to have cabal
automatically hide packages (as oppose to unregister them) to arrive at a
world where all exposed packages are consistent. Extrapolating for the case
you mention above

* if I installed P and then Q, I'd end up with containers-3.1 and Q
exposed, and containers-2.9 and P hidden
* if I installed Q and then P, I'd end up with containers-2.9 and P
exposed, and containers-3.1 and Q hidden

But either way, all four package/versions would be available, and cabal
would be able to select an appropriate subset of packages when configuring.
Does that sound about right?

Michael

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/bfadccc8/attachment.html>

From simonpj at microsoft.com  Mon Mar 23 10:05:56 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Mar 2015 10:05:56 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <CAKA2JgKhM5skNTNGYZVYc+1r70805X6k2hNg=d+SbDm56AxMYA@mail.gmail.com>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
 <CAKA2JgLazjiJ=SA7nPMgH84+ER-YMXJcvWvAErzJvi-ByLBmQw@mail.gmail.com>
 <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net>
 <CAKA2JgKhM5skNTNGYZVYc+1r70805X6k2hNg=d+SbDm56AxMYA@mail.gmail.com>
Message-ID: <f3d5039b4ef74dd299bf8789bf71f275@DB4PR30MB030.064d.mgd.msft.net>

If I'm reading this correctly, the proposal then would be to have cabal automatically hide packages (as oppose to unregister them) to arrive at a world where all exposed packages are consistent. Extrapolating for the case you mention above

* if I installed P and then Q, I'd end up with containers-3.1 and Q exposed, and containers-2.9 and P hidden
* if I installed Q and then P, I'd end up with containers-2.9 and P exposed, and containers-3.1 and Q hidden

But either way, all four package/versions would be available, and cabal would be able to select an appropriate subset of packages when configuring. Does that sound about right?

Correct, esp the bit that I have emboldened. For the former bullets, perhaps Cabal might ask you want you want to do.

That still leaves open questions.  What happens if you say ?ghc ?package P ?package Q Foo.hs??  Should GHC complain that you?ve chosen an inconsistent set?  Perhaps!

(NB if P and Q use containers only internally, and do not expose any types from containers, then arguably it?s ok; but I?d argue for jumping that bridge when we come to it.)

Simon

From: Michael Snoyman [mailto:michael at snoyman.com]
Sent: 23 March 2015 09:58
To: Simon Peyton Jones; cabal-devel at haskell.org
Cc: haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org
Subject: Re: Cabal and simultaneous installations of the same package


On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString."

Reading your blog post [1] it seems that we are addressing different questions:

?         My proposal is only that the act of *installing* a package does not break existing installed package, and is not rejected because it risks doing so.
Thank you for the clarification, I had misread that. On that front: I agree.

?         You agree that the confusing behaviour you describe can?t happen with Cabal.  In any one build, Cabal can ensure that only one version of each package is used in the build, so such a message could never show up.
I've seen people discussing exactly such a change to Cabal's behavior, so I mistakenly took your comments to be heading in that direction. While I think there *might* be some future where we could expose that functionality, it could be incredibly confusing. I'd feel much better starting off with simply the act of installing.

?         What you want is for the confusing behaviour to be true of GHCi too.  Well that?s simple enough: ensure that the set of exposed packages (ie the ones you say ?import M? for), is consistent in the same way.  The point is that I may need to install a bunch of packages to build a program.  If I?m using Cabal, none of those newly installed packages need be exposed; I simply need them there so I can compile my program (using Cabal).   But at the moment I can?t do that.

That leaves open the following question. Suppose

?         I want to install and expose package P and Q

?         But alas, P depends on containers 2.9 and Q depends on containers 3.1
Now I?m stuck. But there is a good reason for being stuck, and one that is explicable.


If I'm reading this correctly, the proposal then would be to have cabal automatically hide packages (as oppose to unregister them) to arrive at a world where all exposed packages are consistent. Extrapolating for the case you mention above

* if I installed P and then Q, I'd end up with containers-3.1 and Q exposed, and containers-2.9 and P hidden
* if I installed Q and then P, I'd end up with containers-2.9 and P exposed, and containers-3.1 and Q hidden

But either way, all four package/versions would be available, and cabal would be able to select an appropriate subset of packages when configuring. Does that sound about right?

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/dc756c7e/attachment-0001.html>

From mietek at bak.io  Mon Mar 23 11:44:49 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Mon, 23 Mar 2015 11:44:49 +0000
Subject: Cabal webpage on haskell.org
In-Reply-To: <CAJCpNrrkyaMwGd-FH7=OxhnFFdvDqQBwZ0gty_LF8DjVJ+-Pew@mail.gmail.com>
References: <68140263-C9E7-42AB-BE0A-6774DCB537F7@bak.io>
 <etPan.550fa8d1.507ed7ab.7ed7@mbp.local>
 <CAJCpNrrkyaMwGd-FH7=OxhnFFdvDqQBwZ0gty_LF8DjVJ+-Pew@mail.gmail.com>
Message-ID: <9FBF0EB5-9022-43F1-B2A6-767DC14A1821@bak.io>

Thanks, Gershom, Ryan.

I made a mistake in my earlier email saying ?1.22.1.0 and 1.22.1.1?, where I meant ?1.22.0.1?.

It looks like the following cabal-install releases are missing from the cabal/releases directory:

- 1.22.0.1
- 1.18.0.5
- 1.18.0
- 1.16.0.2
- 1.16.0.1
- 1.16.0

Additionally, it would be great to have https://www.haskell.org/cabal/release/ CDN-ified as https://downloads.haskell.org/~cabal/, just like https://www.haskell.org/ghc/dist/ is CDN-ified as https://downloads.haskell.org/~ghc/.


-- 
Mi?tek
https://mietek.io




On 2015-03-23, at 08:57, Ryan Thomas <ryan at ryant.org> wrote:

> 1.22.2.0 has been updated on the downloads page. The issue still
> remains the the '-latest' symlinks have not been updated.
> 
> On 23 March 2015 at 05:46, Gershom B <gershomb at gmail.com> wrote:
>> I?ve re-enabled the directory listings for https://www.haskell.org/cabal/release/
>> 
>> (admins, note: I just changed the nginx.conf directly, we need to backport all our changes into the full deploy scripts?)
>> 
>> ?Gershom
>> 
>> On March 15, 2015 at 3:18:52 AM, Mi?tek Bak (mietek at bak.io) wrote:
>>> There are at two problems with the Cabal webpage on haskell.org:
>>> 
>>> 
>>> 1. The release directories are no longer browseable, as attempting to list their contents
>>> fails with 403 errors.
>>> 
>>> Being able to browse these directories was probably the only way to locate binary downloads
>>> for releases older than the one linked from the download page, which is currently 1.22.0.0.
>>> 
>>> https://www.haskell.org/cabal/release/cabal-install-1.22.0.0/
>>> https://www.haskell.org/cabal/release/cabal-install-1.20.0.3/
>>> https://www.haskell.org/cabal/release/
>>> 
>>> 
>>> 2. 1.22.0.0 is still listed as the latest version on the download page, even though 1.22.1.0
>>> and 1.22.1.1 were released 3 weeks ago.
>>> 
>>> https://www.haskell.org/cabal/download.html
>>> https://github.com/haskell/cabal/releases
>>> 
>>> 
>>> How can I help get this fixed?
>>> 
>>> 
>>> --
>>> Mi?tek
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> cabal-devel mailing list
>> cabal-devel at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/c595b3a0/attachment.bin>

From ryan at ryant.org  Mon Mar 23 11:48:38 2015
From: ryan at ryant.org (Ryan Thomas)
Date: Mon, 23 Mar 2015 11:48:38 +0000
Subject: Cabal webpage on haskell.org
In-Reply-To: <9FBF0EB5-9022-43F1-B2A6-767DC14A1821@bak.io>
References: <68140263-C9E7-42AB-BE0A-6774DCB537F7@bak.io>
 <etPan.550fa8d1.507ed7ab.7ed7@mbp.local>
 <CAJCpNrrkyaMwGd-FH7=OxhnFFdvDqQBwZ0gty_LF8DjVJ+-Pew@mail.gmail.com>
 <9FBF0EB5-9022-43F1-B2A6-767DC14A1821@bak.io>
Message-ID: <CAJCpNrqgHK1J=jGhOHW82kUosRN34UogrP6AD81wsO4EepY=Bw@mail.gmail.com>

Thanks, I've raised https://github.com/haskell/cabal/issues/2490 so
that we can track this.

Cheers,

ryan

On 23 March 2015 at 11:44, Mi?tek Bak <mietek at bak.io> wrote:
> Thanks, Gershom, Ryan.
>
> I made a mistake in my earlier email saying ?1.22.1.0 and 1.22.1.1?, where I meant ?1.22.0.1?.
>
> It looks like the following cabal-install releases are missing from the cabal/releases directory:
>
> - 1.22.0.1
> - 1.18.0.5
> - 1.18.0
> - 1.16.0.2
> - 1.16.0.1
> - 1.16.0
>
> Additionally, it would be great to have https://www.haskell.org/cabal/release/ CDN-ified as https://downloads.haskell.org/~cabal/, just like https://www.haskell.org/ghc/dist/ is CDN-ified as https://downloads.haskell.org/~ghc/.
>
>
> --
> Mi?tek
> https://mietek.io
>
>
>
>
> On 2015-03-23, at 08:57, Ryan Thomas <ryan at ryant.org> wrote:
>
>> 1.22.2.0 has been updated on the downloads page. The issue still
>> remains the the '-latest' symlinks have not been updated.
>>
>> On 23 March 2015 at 05:46, Gershom B <gershomb at gmail.com> wrote:
>>> I?ve re-enabled the directory listings for https://www.haskell.org/cabal/release/
>>>
>>> (admins, note: I just changed the nginx.conf directly, we need to backport all our changes into the full deploy scripts?)
>>>
>>> ?Gershom
>>>
>>> On March 15, 2015 at 3:18:52 AM, Mi?tek Bak (mietek at bak.io) wrote:
>>>> There are at two problems with the Cabal webpage on haskell.org:
>>>>
>>>>
>>>> 1. The release directories are no longer browseable, as attempting to list their contents
>>>> fails with 403 errors.
>>>>
>>>> Being able to browse these directories was probably the only way to locate binary downloads
>>>> for releases older than the one linked from the download page, which is currently 1.22.0.0.
>>>>
>>>> https://www.haskell.org/cabal/release/cabal-install-1.22.0.0/
>>>> https://www.haskell.org/cabal/release/cabal-install-1.20.0.3/
>>>> https://www.haskell.org/cabal/release/
>>>>
>>>>
>>>> 2. 1.22.0.0 is still listed as the latest version on the download page, even though 1.22.1.0
>>>> and 1.22.1.1 were released 3 weeks ago.
>>>>
>>>> https://www.haskell.org/cabal/download.html
>>>> https://github.com/haskell/cabal/releases
>>>>
>>>>
>>>> How can I help get this fixed?
>>>>
>>>>
>>>> --
>>>> Mi?tek
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> cabal-devel mailing list
>>> cabal-devel at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>

From johan.tibell at gmail.com  Mon Mar 23 15:05:28 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 23 Mar 2015 16:05:28 +0100
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAK-tuPY_N76CK0p+NEuFjg1d-2qb9mYrA8T40cmHne_TGA6c3g@mail.gmail.com>

On Mon, Mar 23, 2015 at 9:45 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> But time has passed and it hasn't happened. Is this because I'm
> misunderstanding?  Or because it is harder than I think?  Or because there
> are much bigger problems?  Or because there is insufficient effort
> available?  Or what?


I have no idea what the status of this is or if GHC indeed has all the
things we need. Perhaps Edward could comment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/4e7bac97/attachment.html>

From mietek at bak.io  Mon Mar 23 15:28:14 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Mon, 23 Mar 2015 15:28:14 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
 <CAKA2JgLazjiJ=SA7nPMgH84+ER-YMXJcvWvAErzJvi-ByLBmQw@mail.gmail.com>
 <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <E8F8976A-DB48-4C3C-8013-B11FB160F0CF@bak.io>

On 2015-03-23, at 09:52, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> The point is that I may need to install a bunch of packages to build a program.  If I?m using Cabal, none of those newly installed packages need be exposed; I simply need them there so I can compile my program (using Cabal).   But at the moment I can?t do that.

Do you mean that you may need to install a bunch of packages to build a _build-tool_ (such as alex, happy, c2hs, cpps?), in order to compile your program?

If yes, then one way to avoid having these packages pollute your build environment is building each Haskell program in a separate sandbox.

There are some tools which attempt to simplify this process.  Halcyon goes a bit further ? 

Halcyon allows you to declare other Haskell programs to be installed as build-time (or run-time!) dependencies for your program.  If needed, they will be built on-the-fly; otherwise, they will be restored from previously-built archives.

This works around long-standing cabal-install issues:
https://github.com/haskell/cabal/issues/220
https://github.com/haskell/cabal/issues/779

See the Haskell Language source code for an example:
https://halcyon.sh/examples/#haskell-language

See the Halcyon reference for details:
https://halcyon.sh/reference/#halcyon_sandbox_extra_apps
https://halcyon.sh/reference/#halcyon_extra_apps


-- 
Mi?tek
https://mietek.io


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/5c467f82/attachment.bin>

From simonpj at microsoft.com  Mon Mar 23 15:32:39 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Mar 2015 15:32:39 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <CAK-tuPY_N76CK0p+NEuFjg1d-2qb9mYrA8T40cmHne_TGA6c3g@mail.gmail.com>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPY_N76CK0p+NEuFjg1d-2qb9mYrA8T40cmHne_TGA6c3g@mail.gmail.com>
Message-ID: <91d2cf5191134135b65cd6d2ae889422@DB4PR30MB030.064d.mgd.msft.net>

I have no idea what the status of this is or if GHC indeed has all the things we need. Perhaps Edward could comment.
I?m pretty confident that GHC has all the things needed, and has done since last summer.  It?s Cabal that doesn?t!

But as you say, Edward Y can confirm.

Simon

From: Johan Tibell [mailto:johan.tibell at gmail.com]
Sent: 23 March 2015 15:05
To: Simon Peyton Jones
Cc: cabal-devel at haskell.org; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org; Edward Yang
Subject: Re: Cabal and simultaneous installations of the same package

On Mon, Mar 23, 2015 at 9:45 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
But time has passed and it hasn't happened. Is this because I'm misunderstanding?  Or because it is harder than I think?  Or because there are much bigger problems?  Or because there is insufficient effort available?  Or what?

I have no idea what the status of this is or if GHC indeed has all the things we need. Perhaps Edward could comment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/e67bef03/attachment.html>

From mietek at bak.io  Mon Mar 23 16:32:42 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Mon, 23 Mar 2015 16:32:42 +0000
Subject: wither the Platform
In-Reply-To: <CAKA2JgLNkHr7=sExpWO--viL7HD=UkRHcaZyS7V91J1nwyAz2Q@mail.gmail.com>
References: <CAAOoiFYtcBYgevcJinxNwGJNGHtbcT_COmWA=k5Tw21SyLwm9w@mail.gmail.com>
 <CAKA2JgLNkHr7=sExpWO--viL7HD=UkRHcaZyS7V91J1nwyAz2Q@mail.gmail.com>
Message-ID: <4881437D-8D98-49FA-B4A6-CDE6A2A5DA76@bak.io>

On 2015-03-22, at 15:59, Michael Snoyman <michael at snoyman.com> wrote:

> 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.


> 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.

I?d be very happy to contribute to this effort.  In fact, I?ve already spent some of time addressing these issues.

Halcyon already provides a method for installing GHC, cabal-install, build-tools, and other Haskell programs ? on OS X, and many Linux distributions.  FreeBSD and Windows are on the roadmap.

Additionally, Halcyon allows you to declare native OS libraries as build-time (or run-time?) dependencies for Haskell programs.  They will be installed into a user-controlled directory, by wrapping around the native OS package manager.

Currently, this is supported on Debian-based and RedHat-based Linux distributions, which partially implements a long-standing cabal-install feature request:
https://github.com/mietek/halcyon/issues/38
https://github.com/haskell/cabal/issues/571

See the Haskell Language source code for an example:
https://halcyon.sh/examples/#haskell-language

See the Halcyon reference for details:
https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages
https://halcyon.sh/reference/#halcyon_extra_os_packages


-- 
Mi?tek
https://mietek.io


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/b481f108/attachment-0001.bin>

From gershomb at gmail.com  Mon Mar 23 17:31:08 2015
From: gershomb at gmail.com (Gershom B)
Date: Mon, 23 Mar 2015 13:31:08 -0400
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAM8RHpEqfsLDZ5j2_yxDayQ_15eWkmfFHP1Szj8ZK1imZL31-g@mail.gmail.com>

On Mon, Mar 23, 2015 at 4:45 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> |  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.
>
> People mean different things by "cabal hell", but the inability to
>         simultaneously install multiple versions of the same package,
>         compiled against different dependencies
> is certainly one of them, and I think it is the one that Yitzchak is referring to here.

My understanding is that the problem Yitz is discussing is much more
straightforward and easy to fix.

The issue is that if I have an "empty" global package db and enter a
sandbox and cabal-install something, then I will get one package
install plan. But if I have a "well populated" package db, then
attempt to cabal-install something in the sandbox, the plan will
attempt to use the packages from that global db, and so will often be
a different, and perhaps worse plan (especially if it runs into quirks
in the solver).

This is discussed on the associated reddit thread here:
http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmx9v7

As I proposed on the main email thread, I think it would make sense to
make the easy, default option the one which, in sandboxes, effectively
ignores the global db for solving. This leads to more duplication and
longer build times, but it is safer. However, we should have an easy
setting/flag (to be set when initializing a sandbox or any time
thereafter) which can switch the preference over to preferring to use
already installed versions in the global db. That way, new users can,
naively, get a _lot_ of isolation with sandboxes, and those who know
what they are doing can opt out in order to reduce duplication of
installs and cut down on build times.

Addition of a `prefer-global-db` flag and a good default setting for
it (i.e., false) seems to me like it would resolve the _central_ issue
people have with the platform, and situate us well to unilaterally
recommend it as the default install option.

Cheers,
Gershom

From simonpj at microsoft.com  Mon Mar 23 20:13:53 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Mar 2015 20:13:53 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <CAM8RHpEqfsLDZ5j2_yxDayQ_15eWkmfFHP1Szj8ZK1imZL31-g@mail.gmail.com>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>,
 <CAM8RHpEqfsLDZ5j2_yxDayQ_15eWkmfFHP1Szj8ZK1imZL31-g@mail.gmail.com>
Message-ID: <1427141632771.55413@microsoft.com>

But I'm hazy about why sandboxes are needed at all.  As I understand it, they were invented to solve the very problem that is now solved (if only Cabal could take advantage of it).

Simon

________________________________________
From: Gershom B <gershomb at gmail.com>
Sent: 23 March 2015 17:31
To: Simon Peyton Jones
Cc: cabal-devel at haskell.org; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org
Subject: Re: Cabal and simultaneous installations of the same package

On Mon, Mar 23, 2015 at 4:45 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> |  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.
>
> People mean different things by "cabal hell", but the inability to
>         simultaneously install multiple versions of the same package,
>         compiled against different dependencies
> is certainly one of them, and I think it is the one that Yitzchak is referring to here.

My understanding is that the problem Yitz is discussing is much more
straightforward and easy to fix.

The issue is that if I have an "empty" global package db and enter a
sandbox and cabal-install something, then I will get one package
install plan. But if I have a "well populated" package db, then
attempt to cabal-install something in the sandbox, the plan will
attempt to use the packages from that global db, and so will often be
a different, and perhaps worse plan (especially if it runs into quirks
in the solver).

This is discussed on the associated reddit thread here:
http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmx9v7

As I proposed on the main email thread, I think it would make sense to
make the easy, default option the one which, in sandboxes, effectively
ignores the global db for solving. This leads to more duplication and
longer build times, but it is safer. However, we should have an easy
setting/flag (to be set when initializing a sandbox or any time
thereafter) which can switch the preference over to preferring to use
already installed versions in the global db. That way, new users can,
naively, get a _lot_ of isolation with sandboxes, and those who know
what they are doing can opt out in order to reduce duplication of
installs and cut down on build times.

Addition of a `prefer-global-db` flag and a good default setting for
it (i.e., false) seems to me like it would resolve the _central_ issue
people have with the platform, and situate us well to unilaterally
recommend it as the default install option.

Cheers,
Gershom

From duncan.coutts at googlemail.com  Mon Mar 23 22:07:32 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Mon, 23 Mar 2015 22:07:32 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1427148452.11324.439.camel@dunky.localdomain>

On Mon, 2015-03-23 at 08:45 +0000, Simon Peyton Jones wrote:
> Dear Cabal developers
> 
> You'll probably have seen the thread about the Haskell Platform.
> 
> Among other things, this point arose:
> 
> |  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.
> 
> People mean different things by "cabal hell", but the inability to 
> 	simultaneously install multiple versions of the same package,
> 	compiled against different dependencies
> is certainly one of them, and I think it is the one that Yitzchak is referring to here.
> 
> But some time now GHC has allowed multiple versions of the same
> package (compiled against different dependencies) to be installed
> simultaneously.

That's technically true of existing ghc versions, though ghc-pkg does
not directly allow registering multiple instances of the same version of
a package.

As of 7.10 we can actually use ghc-pkg to register multiple instances,
using ghc-pkg register --enable-multi-instance

Also since 7.10 we can have "environment" files that say what packages
to expose. There can be a per-user default one, or per-user named ones
(which can be used via the ghc command line or via env var), or local
environments in a directory.

While Cabal has always built things with consistent deps and solved the
problem of "which ByteString do I mean", the same has not been true for
GHCi. With this new environment mechanism Cabal can create the
environments and then when the user runs ghc/ghci then they get the set
of packages previously set up by Cabal.

Elsewhere in this thread you say:

> What you want is for the confusing behaviour to be true of GHCi too.
> Well that?s simple enough: ensure that the set of exposed packages (ie
> the ones you say ?import M? for), is consistent in the same way.  The
> point is that I may need to install a bunch of packages to build a
> program.  If I?m using Cabal, none of those newly installed packages
> need be exposed; I simply need them there so I can compile my program
> (using Cabal).   But at the moment I can?t do that.

Yes, that is exactly what these environment files are intended for.

Myself and Edsko implemented these features (for the IHG) to enable
future Cabal versions to take the multi instance approach fully.

> So all we need to do is to fix Cabal to allow it too, and thereby kill
> of a huge class of cabal-hell problems at one blow.

With these features now implemented in GHC we're in a position to turn
attention to Cabal to make use of them.

> But time has passed and it hasn't happened. Is this because I'm
> misunderstanding?  Or because it is harder than I think?  Or because
> there are much bigger problems?  Or because there is insufficient
> effort available?  Or what?

There's a number of parts remaining to do.

> Unless I'm way off beam, this "multiple installations of the same
> package" thing has been a huge pain forever, and the solution is
> within our grasp.  What's stopping us grasping it?

Yes, we're closer than ever. I covered more of the details in this blog
post:

http://www.well-typed.com/blog/preview/how-we-might-abolish-cabal-hell-2/

So some of the remaining parts:

Cabal needs to assign proper installed package ids, like nix does. These
should be based on the hash of all inputs to a package build. In
particular that means a hash of the content of the sources. This is easy
for tarballs but a bit harder to do accurately for unpacked build trees.

There are some new UI issues to deal with. The user interface will have
to make this issue of multiple consistent environments be explicit in
the user interface. We need to know what env we are in, what is in it,
what other envs are available and be able to switch between them.

Suppose that we enforce that each environment be fully consistent. Then
when I "cabal install Q" and it cannot find a solution to install
everything in the current environment plus the one extra package such
that they all have consistent deps, then what should it do? Suppose that
Q really could be installed on its own, but cannot be installed
consistently with the other things in this env. Should it suggest that
you make a new environment? There are some details to work out here so
that we don't make a confusing UI.

There's also an unresolved issue about when we try to reuse existing
installed dependencies. One approach is to say that we make install
plans without considering what is already available in the package
store, and then only re-use existing ones if the installed package Ids
happen to match up. The other approach is to say that the solver should
actively try to reuse installed instances when it can. The latter is
what we do now, to try and reduce the number of reinstalls. But when
there are dozens of versions available this is harder: we need to know
more information to know if it is safe to re-use an existing instance.
(There are examples where it's clearly not safe to reuse packages.) Or a
pragmatic approach might be to try and reuse existing installed
instances within the current environment but not actively try to reuse
other instances available in the package store.


On a related topic, along with the London HUG we're trying to organise a
couple infrastructure hackathons in London. The aim would be to work on
Cabal/Hackage related things. The plan is to have two hackathons 6-8
weeks apart, to get new people set up with projects at the first and to
get things merged in the second. For Cabal, this project would be my
focus, trying to get people to work on different aspects of it. I gave a
talk at the London HUG recently about getting involved with hacking on
Cabal/Hackage.

Duncan


From duncan.coutts at googlemail.com  Mon Mar 23 22:10:09 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Mon, 23 Mar 2015 22:10:09 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <1427141632771.55413@microsoft.com>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
 , <CAM8RHpEqfsLDZ5j2_yxDayQ_15eWkmfFHP1Szj8ZK1imZL31-g@mail.gmail.com>
 <1427141632771.55413@microsoft.com>
Message-ID: <1427148609.11324.441.camel@dunky.localdomain>

On Mon, 2015-03-23 at 20:13 +0000, Simon Peyton Jones wrote:
> But I'm hazy about why sandboxes are needed at all.  As I understand
> it, they were invented to solve the very problem that is now solved
> (if only Cabal could take advantage of it).

Yes, the nix approach would subsume sandboxes.

I cover this in this post
http://www.well-typed.com/blog/preview/how-we-might-abolish-cabal-hell-2/


Duncan


From duncan.coutts at googlemail.com  Mon Mar 23 22:33:15 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Mon, 23 Mar 2015 22:33:15 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <1427148609.11324.441.camel@dunky.localdomain>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
 , <CAM8RHpEqfsLDZ5j2_yxDayQ_15eWkmfFHP1Szj8ZK1imZL31-g@mail.gmail.com>
 <1427141632771.55413@microsoft.com>
 <1427148609.11324.441.camel@dunky.localdomain>
Message-ID: <1427149995.11324.448.camel@dunky.localdomain>

On Mon, 2015-03-23 at 22:10 +0000, Duncan Coutts wrote:
> On Mon, 2015-03-23 at 20:13 +0000, Simon Peyton Jones wrote:
> > But I'm hazy about why sandboxes are needed at all.  As I understand
> > it, they were invented to solve the very problem that is now solved
> > (if only Cabal could take advantage of it).
> 
> Yes, the nix approach would subsume sandboxes.
> 
> I cover this in this post
> http://www.well-typed.com/blog/preview/how-we-might-abolish-cabal-hell-2/

Oops, permanent link:

http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part-2/



From M.W.Wang at kent.ac.uk  Tue Mar 24 15:21:27 2015
From: M.W.Wang at kent.ac.uk (Meng Wang)
Date: Tue, 24 Mar 2015 15:21:27 +0000
Subject: hackage statistics
Message-ID: <AF0E40BB-AE78-42B4-80F2-89499D56C0D4@kent.ac.uk>

Hi,

A few of us are writing a survey of FP and would like to include some statistic graphs of Haskell (similar to those found here:http://galois.com/blog/2009/03/one-million-haskell-downloads/). Does anyone know how I can obtain such data?

Thank you very much,
Meng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150324/9bc62d4d/attachment.html>

From mietek at bak.io  Wed Mar 25 12:26:50 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Wed, 25 Mar 2015 12:26:50 +0000
Subject: Version constraints and cabal.config files
In-Reply-To: <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
References: <CAAJHNPDtG6L6gNGmY=arZdM_UWFdmQzueLAQH1pLA8VzEnsOtQ@mail.gmail.com>
 <D140E7E4-53AE-476A-835F-5B2A27E5DE90@bak.io>
 <CAAJHNPAJQYkjqQ1T6T4+v5EuFb92h8wP9yJT8EDuQucyLNhm+A@mail.gmail.com>
 <7D1B82EE-B31C-421E-9A12-FF1B4CCBAD28@bak.io>
 <CAAJHNPA9cDWk-EDYxLOKS77jHaZrvDZQ-yU+JMObPD1-5TEiZQ@mail.gmail.com>
 <B126AFC3-F97A-49F8-B833-667CBE66EBC3@bak.io>
 <CAKA2JgLdu+Zrfg6NKU-Y9WG86AKYstUL9J2YB1NC74wyKBOHrA@mail.gmail.com>
 <5E73356C-1973-4374-A706-A92359E96F08@bak.io>
 <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
Message-ID: <05FE5722-5E2C-40A7-891C-18BC1DC3CA8C@bak.io>

On 2015-03-25, at 12:16, Michael Snoyman <michael at fpcomplete.com> wrote:

> Trying to understand the problem: currently, with your approach, if the project depends on a library not in the LTS Haskell release, then the cabal-install dependency solver won't be able to find it. Instead, you'd like to be able to use the dependency solver to track down those extra dependencies. Is that correct?
> 
> If so, why not take a multi-pass approach: download the cabal.config from stackage.org (which creates an inclusive snapshot), and then use --dry-run, which will tell you all the packages to be used.

You?re correct.  However, this will have to be `cabal install --dependencies-only --dry-run`, and not `cabal freeze --dry-run`, because `cabal freeze` always completely ignores any existing version constraints, whether local or global (https://github.com/haskell/cabal/issues/2265).

I?m planning to switch away from `cabal freeze` soon, but it?s not going to be a drop-in replacement (https://github.com/mietek/halcyon/issues/52).

This is a good moment to carefully consider the meaning of a per-application `cabal.config` file, and whether the `cabal freeze` flavour should be completely replaced by separate constraints files.  Perhaps, as mentioned in the original `cabal freeze` proposal, we could also have separate constraints sets for different GHC versions.

I?m hoping Cabal developers could chime in on the discussion.


-- 
Mi?tek
https://mietek.io


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150325/b580232f/attachment.bin>

From michael at snoyman.com  Wed Mar 25 14:24:19 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 25 Mar 2015 14:24:19 +0000
Subject: [Haskell-cafe] Version constraints and cabal.config files
In-Reply-To: <CADch-tLMrJJG_u5Lt==dO8-FxCm3EzO+6W0ZdMuWQe5Finu=WA@mail.gmail.com>
References: <CAAJHNPDtG6L6gNGmY=arZdM_UWFdmQzueLAQH1pLA8VzEnsOtQ@mail.gmail.com>
 <D140E7E4-53AE-476A-835F-5B2A27E5DE90@bak.io>
 <CAAJHNPAJQYkjqQ1T6T4+v5EuFb92h8wP9yJT8EDuQucyLNhm+A@mail.gmail.com>
 <7D1B82EE-B31C-421E-9A12-FF1B4CCBAD28@bak.io>
 <CAAJHNPA9cDWk-EDYxLOKS77jHaZrvDZQ-yU+JMObPD1-5TEiZQ@mail.gmail.com>
 <B126AFC3-F97A-49F8-B833-667CBE66EBC3@bak.io>
 <CAKA2JgLdu+Zrfg6NKU-Y9WG86AKYstUL9J2YB1NC74wyKBOHrA@mail.gmail.com>
 <5E73356C-1973-4374-A706-A92359E96F08@bak.io>
 <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
 <05FE5722-5E2C-40A7-891C-18BC1DC3CA8C@bak.io>
 <CADch-tLMrJJG_u5Lt==dO8-FxCm3EzO+6W0ZdMuWQe5Finu=WA@mail.gmail.com>
Message-ID: <CAKA2Jg+WXH7BTh=pOJduvaYn7RA6M0+PMG9HegRjFz6f72bfHA@mail.gmail.com>

On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <acowley at seas.upenn.edu>
wrote:

> The suggestion to use "cabal install --dependencies-only ..." instead
> of "cabal freeze" in that issue is really nicely presented. "cabal
> freeze" is close to the right thing, but it's just not as fully
> featured as "cabal install" (e.g. taking flags).
>
> As for Stackage, I think it would be helpful to cache the full build
> plans computed for each package in Stackage. This is most of the work
> my Nix tooling currently does, so it would be a big time saver.
>
>
>
By "full build plans," do you mean the dist/setup-config file, or something
else? That file would be problematic since it's Cabal-library-version
specific IIRC. If you're looking for the full listing of deep dependencies
and versions, we can extract that from the .yaml file using the technique I
mentioned earlier.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150325/e403d2c2/attachment.html>

From michael at snoyman.com  Wed Mar 25 14:51:22 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 25 Mar 2015 14:51:22 +0000
Subject: [Haskell-cafe] Version constraints and cabal.config files
In-Reply-To: <CADch-tLtn0JTshORAgMi+mgEW+Ukxox5Hkzrk7s7eVqoJdJ_oQ@mail.gmail.com>
References: <CAAJHNPDtG6L6gNGmY=arZdM_UWFdmQzueLAQH1pLA8VzEnsOtQ@mail.gmail.com>
 <D140E7E4-53AE-476A-835F-5B2A27E5DE90@bak.io>
 <CAAJHNPAJQYkjqQ1T6T4+v5EuFb92h8wP9yJT8EDuQucyLNhm+A@mail.gmail.com>
 <7D1B82EE-B31C-421E-9A12-FF1B4CCBAD28@bak.io>
 <CAAJHNPA9cDWk-EDYxLOKS77jHaZrvDZQ-yU+JMObPD1-5TEiZQ@mail.gmail.com>
 <B126AFC3-F97A-49F8-B833-667CBE66EBC3@bak.io>
 <CAKA2JgLdu+Zrfg6NKU-Y9WG86AKYstUL9J2YB1NC74wyKBOHrA@mail.gmail.com>
 <5E73356C-1973-4374-A706-A92359E96F08@bak.io>
 <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
 <05FE5722-5E2C-40A7-891C-18BC1DC3CA8C@bak.io>
 <CADch-tLMrJJG_u5Lt==dO8-FxCm3EzO+6W0ZdMuWQe5Finu=WA@mail.gmail.com>
 <CAKA2Jg+WXH7BTh=pOJduvaYn7RA6M0+PMG9HegRjFz6f72bfHA@mail.gmail.com>
 <CADch-tLtn0JTshORAgMi+mgEW+Ukxox5Hkzrk7s7eVqoJdJ_oQ@mail.gmail.com>
Message-ID: <CAKA2JgK63uYfZ50-fiO53o1YCQcf80LHRoLg=K2NAsJKLOGJ+A@mail.gmail.com>

On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley at seas.upenn.edu>
wrote:

> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael at snoyman.com>
> wrote:
> >
> >
> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <acowley at seas.upenn.edu>
> > wrote:
> >>
> >> The suggestion to use "cabal install --dependencies-only ..." instead
> >> of "cabal freeze" in that issue is really nicely presented. "cabal
> >> freeze" is close to the right thing, but it's just not as fully
> >> featured as "cabal install" (e.g. taking flags).
> >>
> >> As for Stackage, I think it would be helpful to cache the full build
> >> plans computed for each package in Stackage. This is most of the work
> >> my Nix tooling currently does, so it would be a big time saver.
> >>
> >>
> >
> > By "full build plans," do you mean the dist/setup-config file, or
> something
> > else? That file would be problematic since it's Cabal-library-version
> > specific IIRC. If you're looking for the full listing of deep
> dependencies
> > and versions, we can extract that from the .yaml file using the
> technique I
> > mentioned earlier.
> >
> > Michael
>
> Yes, I meant the full listing of deep dependencies.
>
>
>
I've put together a Gist with an executable that does what I described:

https://gist.github.com/snoyberg/5b244331533fcb614523

You give it three arguments on the command line:

* LTS version, e.g. 1.14
* Name of package being checked
* true == only include dependencies of the library and executable, anything
else == include test and benchmark dependencies as well

If that's useful, I can package that up and put it on Hackage.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150325/21919fdb/attachment.html>

From michael at snoyman.com  Wed Mar 25 15:03:38 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 25 Mar 2015 15:03:38 +0000
Subject: [Haskell-cafe] Version constraints and cabal.config files
In-Reply-To: <25FD20FD-AF3C-4122-857F-D3AD4FF4218E@gmail.com>
References: <CAAJHNPDtG6L6gNGmY=arZdM_UWFdmQzueLAQH1pLA8VzEnsOtQ@mail.gmail.com>
 <D140E7E4-53AE-476A-835F-5B2A27E5DE90@bak.io>
 <CAAJHNPAJQYkjqQ1T6T4+v5EuFb92h8wP9yJT8EDuQucyLNhm+A@mail.gmail.com>
 <7D1B82EE-B31C-421E-9A12-FF1B4CCBAD28@bak.io>
 <CAAJHNPA9cDWk-EDYxLOKS77jHaZrvDZQ-yU+JMObPD1-5TEiZQ@mail.gmail.com>
 <B126AFC3-F97A-49F8-B833-667CBE66EBC3@bak.io>
 <CAKA2JgLdu+Zrfg6NKU-Y9WG86AKYstUL9J2YB1NC74wyKBOHrA@mail.gmail.com>
 <5E73356C-1973-4374-A706-A92359E96F08@bak.io>
 <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
 <05FE5722-5E2C-40A7-891C-18BC1DC3CA8C@bak.io>
 <CADch-tLMrJJG_u5Lt==dO8-FxCm3EzO+6W0ZdMuWQe5Finu=WA@mail.gmail.com>
 <CAKA2Jg+WXH7BTh=pOJduvaYn7RA6M0+PMG9HegRjFz6f72bfHA@mail.gmail.com>
 <CADch-tLtn0JTshORAgMi+mgEW+Ukxox5Hkzrk7s7eVqoJdJ_oQ@mail.gmail.com>
 <CAKA2JgK63uYfZ50-fiO53o1YCQcf80LHRoLg=K2NAsJKLOGJ+A@mail.gmail.com>
 <25FD20FD-AF3C-4122-857F-D3AD4FF4218E@gmail.com>
Message-ID: <CAKA2JgLZp7H1_e+mJ2XYYnt2pACCbKfF7-g9z6vdUkezcV+8bQ@mail.gmail.com>

On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley at gmail.com> wrote:

>
>
> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
>
>
> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley at seas.upenn.edu>
> wrote:
>
>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael at snoyman.com>
>> wrote:
>> >
>> >
>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <acowley at seas.upenn.edu>
>> > wrote:
>> >>
>> >> The suggestion to use "cabal install --dependencies-only ..." instead
>> >> of "cabal freeze" in that issue is really nicely presented. "cabal
>> >> freeze" is close to the right thing, but it's just not as fully
>> >> featured as "cabal install" (e.g. taking flags).
>> >>
>> >> As for Stackage, I think it would be helpful to cache the full build
>> >> plans computed for each package in Stackage. This is most of the work
>> >> my Nix tooling currently does, so it would be a big time saver.
>> >>
>> >>
>> >
>> > By "full build plans," do you mean the dist/setup-config file, or
>> something
>> > else? That file would be problematic since it's Cabal-library-version
>> > specific IIRC. If you're looking for the full listing of deep
>> dependencies
>> > and versions, we can extract that from the .yaml file using the
>> technique I
>> > mentioned earlier.
>> >
>> > Michael
>>
>> Yes, I meant the full listing of deep dependencies.
>>
>>
>>
> I've put together a Gist with an executable that does what I described:
>
> https://gist.github.com/snoyberg/5b244331533fcb614523
>
> You give it three arguments on the command line:
>
> * LTS version, e.g. 1.14
> * Name of package being checked
> * true == only include dependencies of the library and executable,
> anything else == include test and benchmark dependencies as well
>
> If that's useful, I can package that up and put it on Hackage.
>
> Michael
>
>
> This is very helpfulness, thanks! There is a bootstrapping issue, though,
> which is, I imagine, why both Mi?tek and I have been writing much more bash
> than we'd like. But perhaps this becomes part of a cabal-install-like
> bootstrap.sh script to get things going.
>
> Anthony
>

Oh, that's actually a great idea. What if we had a program that:

1. takes a set of packages that needs to be installed, and an LTS version
2. computes the dependency tree
3. writes out a shell script (possibly batch program?) to wget, tar xf, and
runghc Setup.hs in the correct order to get all of those packages installed

As you can tell from the program I just threw together, stackage-types
supports this kind of thing pretty trivially.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150325/007759d7/attachment-0001.html>

From michael at snoyman.com  Thu Mar 26 07:21:53 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 26 Mar 2015 07:21:53 +0000
Subject: [Haskell-cafe] Version constraints and cabal.config files
In-Reply-To: <13826087-C1FC-4C71-B3E3-102188A05A2B@gmail.com>
References: <CAAJHNPDtG6L6gNGmY=arZdM_UWFdmQzueLAQH1pLA8VzEnsOtQ@mail.gmail.com>
 <D140E7E4-53AE-476A-835F-5B2A27E5DE90@bak.io>
 <CAAJHNPAJQYkjqQ1T6T4+v5EuFb92h8wP9yJT8EDuQucyLNhm+A@mail.gmail.com>
 <7D1B82EE-B31C-421E-9A12-FF1B4CCBAD28@bak.io>
 <CAAJHNPA9cDWk-EDYxLOKS77jHaZrvDZQ-yU+JMObPD1-5TEiZQ@mail.gmail.com>
 <B126AFC3-F97A-49F8-B833-667CBE66EBC3@bak.io>
 <CAKA2JgLdu+Zrfg6NKU-Y9WG86AKYstUL9J2YB1NC74wyKBOHrA@mail.gmail.com>
 <5E73356C-1973-4374-A706-A92359E96F08@bak.io>
 <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
 <05FE5722-5E2C-40A7-891C-18BC1DC3CA8C@bak.io>
 <CADch-tLMrJJG_u5Lt==dO8-FxCm3EzO+6W0ZdMuWQe5Finu=WA@mail.gmail.com>
 <CAKA2Jg+WXH7BTh=pOJduvaYn7RA6M0+PMG9HegRjFz6f72bfHA@mail.gmail.com>
 <CADch-tLtn0JTshORAgMi+mgEW+Ukxox5Hkzrk7s7eVqoJdJ_oQ@mail.gmail.com>
 <CAKA2JgK63uYfZ50-fiO53o1YCQcf80LHRoLg=K2NAsJKLOGJ+A@mail.gmail.com>
 <25FD20FD-AF3C-4122-857F-D3AD4FF4218E@gmail.com>
 <CAKA2JgLZp7H1_e+mJ2XYYnt2pACCbKfF7-g9z6vdUkezcV+8bQ@mail.gmail.com>
 <13826087-C1FC-4C71-B3E3-102188A05A2B@gmail.com>
Message-ID: <CAKA2JgJK9n-eoesgFWzk93qF66b7t6qN03PZ7En_kJbUuvo6HA@mail.gmail.com>

On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley at gmail.com> wrote:

>
>
>
> On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
>
>
> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley at gmail.com> wrote:
>
>>
>>
>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael at snoyman.com>
>> wrote:
>>
>>
>>
>> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley at seas.upenn.edu>
>> wrote:
>>
>>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael at snoyman.com>
>>> wrote:
>>> >
>>> >
>>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <acowley at seas.upenn.edu
>>> >
>>> > wrote:
>>> >>
>>> >> The suggestion to use "cabal install --dependencies-only ..." instead
>>> >> of "cabal freeze" in that issue is really nicely presented. "cabal
>>> >> freeze" is close to the right thing, but it's just not as fully
>>> >> featured as "cabal install" (e.g. taking flags).
>>> >>
>>> >> As for Stackage, I think it would be helpful to cache the full build
>>> >> plans computed for each package in Stackage. This is most of the work
>>> >> my Nix tooling currently does, so it would be a big time saver.
>>> >>
>>> >>
>>> >
>>> > By "full build plans," do you mean the dist/setup-config file, or
>>> something
>>> > else? That file would be problematic since it's Cabal-library-version
>>> > specific IIRC. If you're looking for the full listing of deep
>>> dependencies
>>> > and versions, we can extract that from the .yaml file using the
>>> technique I
>>> > mentioned earlier.
>>> >
>>> > Michael
>>>
>>> Yes, I meant the full listing of deep dependencies.
>>>
>>>
>>>
>> I've put together a Gist with an executable that does what I described:
>>
>> https://gist.github.com/snoyberg/5b244331533fcb614523
>>
>> You give it three arguments on the command line:
>>
>> * LTS version, e.g. 1.14
>> * Name of package being checked
>> * true == only include dependencies of the library and executable,
>> anything else == include test and benchmark dependencies as well
>>
>> If that's useful, I can package that up and put it on Hackage.
>>
>> Michael
>>
>>
>> This is very helpfulness, thanks! There is a bootstrapping issue, though,
>> which is, I imagine, why both Mi?tek and I have been writing much more bash
>> than we'd like. But perhaps this becomes part of a cabal-install-like
>> bootstrap.sh script to get things going.
>>
>> Anthony
>>
>
> Oh, that's actually a great idea. What if we had a program that:
>
> 1. takes a set of packages that needs to be installed, and an LTS version
> 2. computes the dependency tree
> 3. writes out a shell script (possibly batch program?) to wget, tar xf,
> and runghc Setup.hs in the correct order to get all of those packages
> installed
>
> As you can tell from the program I just threw together, stackage-types
> supports this kind of thing pretty trivially.
>
> Michael
>
>
> Yes, that's what the Nix tooling does. The extra bits are building up
> package databases suitable for each build without copying files all over
> the place. That has the extra benefit of being able to reuse builds when
> the recipe is unchanged. It is definitely not hard, but getting the build
> plans from stackage in a portable way would be valuable.
>
> Anthony
>

OK, I've updated the Gist so that it produces a shell script that will
install all necessary packages. It also has a nicer optparse-applicative
interface now.

https://gist.github.com/snoyberg/5b244331533fcb614523

One thing I didn't do here is add support for custom GHC package databases.
I assume you'll need that, but wasn't sure exactly how you're doing that in
Nix.

If this is useful for you, I'll start a stackage-bootstrap repo, clean up
this code a bit, and we can continue improving it from there.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150326/4256932f/attachment.html>

From michael at snoyman.com  Thu Mar 26 13:41:56 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 26 Mar 2015 13:41:56 +0000
Subject: [Haskell-cafe] Version constraints and cabal.config files
In-Reply-To: <97BBBDDB-1D2C-49E4-82F3-A2445B14DDF7@gmail.com>
References: <CAAJHNPDtG6L6gNGmY=arZdM_UWFdmQzueLAQH1pLA8VzEnsOtQ@mail.gmail.com>
 <D140E7E4-53AE-476A-835F-5B2A27E5DE90@bak.io>
 <CAAJHNPAJQYkjqQ1T6T4+v5EuFb92h8wP9yJT8EDuQucyLNhm+A@mail.gmail.com>
 <7D1B82EE-B31C-421E-9A12-FF1B4CCBAD28@bak.io>
 <CAAJHNPA9cDWk-EDYxLOKS77jHaZrvDZQ-yU+JMObPD1-5TEiZQ@mail.gmail.com>
 <B126AFC3-F97A-49F8-B833-667CBE66EBC3@bak.io>
 <CAKA2JgLdu+Zrfg6NKU-Y9WG86AKYstUL9J2YB1NC74wyKBOHrA@mail.gmail.com>
 <5E73356C-1973-4374-A706-A92359E96F08@bak.io>
 <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
 <05FE5722-5E2C-40A7-891C-18BC1DC3CA8C@bak.io>
 <CADch-tLMrJJG_u5Lt==dO8-FxCm3EzO+6W0ZdMuWQe5Finu=WA@mail.gmail.com>
 <CAKA2Jg+WXH7BTh=pOJduvaYn7RA6M0+PMG9HegRjFz6f72bfHA@mail.gmail.com>
 <CADch-tLtn0JTshORAgMi+mgEW+Ukxox5Hkzrk7s7eVqoJdJ_oQ@mail.gmail.com>
 <CAKA2JgK63uYfZ50-fiO53o1YCQcf80LHRoLg=K2NAsJKLOGJ+A@mail.gmail.com>
 <25FD20FD-AF3C-4122-857F-D3AD4FF4218E@gmail.com>
 <CAKA2JgLZp7H1_e+mJ2XYYnt2pACCbKfF7-g9z6vdUkezcV+8bQ@mail.gmail.com>
 <13826087-C1FC-4C71-B3E3-102188A05A2B@gmail.com>
 <CAKA2JgJK9n-eoesgFWzk93qF66b7t6qN03PZ7En_kJbUuvo6HA@mail.gmail.com>
 <97BBBDDB-1D2C-49E4-82F3-A2445B14DDF7@gmail.com>
Message-ID: <CAKA2JgJLVNU=ciFAZYmA39XNrXkYfBVgimgU8Q90LzrycFg35A@mail.gmail.com>

Is the idea that you'd be able to make a query such as:

GET
https://www.stackage.org/lts/1.14/build-plan?package=foo&package=bar&package=baz

And get a result such as:

[ {"name":"foo", "version":"1.2.3"}
, ...
]

?

On Thu, Mar 26, 2015 at 3:00 PM Anthony Cowley <acowley at gmail.com> wrote:

>
>
>
> On Mar 26, 2015, at 3:21 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
>
>
> On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley at gmail.com> wrote:
>
>>
>>
>>
>> On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael at snoyman.com>
>> wrote:
>>
>>
>>
>> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley at gmail.com> wrote:
>>
>>>
>>>
>>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael at snoyman.com>
>>> wrote:
>>>
>>>
>>>
>>> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley at seas.upenn.edu>
>>> wrote:
>>>
>>>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael at snoyman.com>
>>>> wrote:
>>>> >
>>>> >
>>>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <
>>>> acowley at seas.upenn.edu>
>>>> > wrote:
>>>> >>
>>>> >> The suggestion to use "cabal install --dependencies-only ..." instead
>>>> >> of "cabal freeze" in that issue is really nicely presented. "cabal
>>>> >> freeze" is close to the right thing, but it's just not as fully
>>>> >> featured as "cabal install" (e.g. taking flags).
>>>> >>
>>>> >> As for Stackage, I think it would be helpful to cache the full build
>>>> >> plans computed for each package in Stackage. This is most of the work
>>>> >> my Nix tooling currently does, so it would be a big time saver.
>>>> >>
>>>> >>
>>>> >
>>>> > By "full build plans," do you mean the dist/setup-config file, or
>>>> something
>>>> > else? That file would be problematic since it's Cabal-library-version
>>>> > specific IIRC. If you're looking for the full listing of deep
>>>> dependencies
>>>> > and versions, we can extract that from the .yaml file using the
>>>> technique I
>>>> > mentioned earlier.
>>>> >
>>>> > Michael
>>>>
>>>> Yes, I meant the full listing of deep dependencies.
>>>>
>>>>
>>>>
>>> I've put together a Gist with an executable that does what I described:
>>>
>>> https://gist.github.com/snoyberg/5b244331533fcb614523
>>>
>>> You give it three arguments on the command line:
>>>
>>> * LTS version, e.g. 1.14
>>> * Name of package being checked
>>> * true == only include dependencies of the library and executable,
>>> anything else == include test and benchmark dependencies as well
>>>
>>> If that's useful, I can package that up and put it on Hackage.
>>>
>>> Michael
>>>
>>>
>>> This is very helpfulness, thanks! There is a bootstrapping issue,
>>> though, which is, I imagine, why both Mi?tek and I have been writing much
>>> more bash than we'd like. But perhaps this becomes part of a
>>> cabal-install-like bootstrap.sh script to get things going.
>>>
>>> Anthony
>>>
>>
>> Oh, that's actually a great idea. What if we had a program that:
>>
>> 1. takes a set of packages that needs to be installed, and an LTS version
>> 2. computes the dependency tree
>> 3. writes out a shell script (possibly batch program?) to wget, tar xf,
>> and runghc Setup.hs in the correct order to get all of those packages
>> installed
>>
>> As you can tell from the program I just threw together, stackage-types
>> supports this kind of thing pretty trivially.
>>
>> Michael
>>
>>
>> Yes, that's what the Nix tooling does. The extra bits are building up
>> package databases suitable for each build without copying files all over
>> the place. That has the extra benefit of being able to reuse builds when
>> the recipe is unchanged. It is definitely not hard, but getting the build
>> plans from stackage in a portable way would be valuable.
>>
>> Anthony
>>
>
> OK, I've updated the Gist so that it produces a shell script that will
> install all necessary packages. It also has a nicer optparse-applicative
> interface now.
>
> https://gist.github.com/snoyberg/5b244331533fcb614523
>
> One thing I didn't do here is add support for custom GHC package
> databases. I assume you'll need that, but wasn't sure exactly how you're
> doing that in Nix.
>
> If this is useful for you, I'll start a stackage-bootstrap repo, clean up
> this code a bit, and we can continue improving it from there.
>
> Michael
>
>
> Just having a URL from which to GET the build plan would be most useful.
> As you say, the actual package building happens after DB creation, and that
> requires knowing what to put in the DB.
>
> Anthony
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150326/bccb3ba1/attachment.html>

From michael at snoyman.com  Thu Mar 26 14:50:06 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 26 Mar 2015 14:50:06 +0000
Subject: [Haskell-cafe] Version constraints and cabal.config files
In-Reply-To: <15013C71-D09D-48C0-8954-F430DA251F5D@gmail.com>
References: <CAAJHNPDtG6L6gNGmY=arZdM_UWFdmQzueLAQH1pLA8VzEnsOtQ@mail.gmail.com>
 <D140E7E4-53AE-476A-835F-5B2A27E5DE90@bak.io>
 <CAAJHNPAJQYkjqQ1T6T4+v5EuFb92h8wP9yJT8EDuQucyLNhm+A@mail.gmail.com>
 <7D1B82EE-B31C-421E-9A12-FF1B4CCBAD28@bak.io>
 <CAAJHNPA9cDWk-EDYxLOKS77jHaZrvDZQ-yU+JMObPD1-5TEiZQ@mail.gmail.com>
 <B126AFC3-F97A-49F8-B833-667CBE66EBC3@bak.io>
 <CAKA2JgLdu+Zrfg6NKU-Y9WG86AKYstUL9J2YB1NC74wyKBOHrA@mail.gmail.com>
 <5E73356C-1973-4374-A706-A92359E96F08@bak.io>
 <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
 <05FE5722-5E2C-40A7-891C-18BC1DC3CA8C@bak.io>
 <CADch-tLMrJJG_u5Lt==dO8-FxCm3EzO+6W0ZdMuWQe5Finu=WA@mail.gmail.com>
 <CAKA2Jg+WXH7BTh=pOJduvaYn7RA6M0+PMG9HegRjFz6f72bfHA@mail.gmail.com>
 <CADch-tLtn0JTshORAgMi+mgEW+Ukxox5Hkzrk7s7eVqoJdJ_oQ@mail.gmail.com>
 <CAKA2JgK63uYfZ50-fiO53o1YCQcf80LHRoLg=K2NAsJKLOGJ+A@mail.gmail.com>
 <25FD20FD-AF3C-4122-857F-D3AD4FF4218E@gmail.com>
 <CAKA2JgLZp7H1_e+mJ2XYYnt2pACCbKfF7-g9z6vdUkezcV+8bQ@mail.gmail.com>
 <13826087-C1FC-4C71-B3E3-102188A05A2B@gmail.com>
 <CAKA2JgJK9n-eoesgFWzk93qF66b7t6qN03PZ7En_kJbUuvo6HA@mail.gmail.com>
 <97BBBDDB-1D2C-49E4-82F3-A2445B14DDF7@gmail.com>
 <CAKA2JgJLVNU=ciFAZYmA39XNrXkYfBVgimgU8Q90LzrycFg35A@mail.gmail.com>
 <15013C71-D09D-48C0-8954-F430DA251F5D@gmail.com>
Message-ID: <CAKA2JgL6W7AFM6JZfmQvYp8+Hsj4zpTKZW8O1fVE=WSjd=jm0Q@mail.gmail.com>

And do you want the information on the core packages (e.g., base,
template-haskell, containers) as well, or should they be left out?

On Thu, Mar 26, 2015 at 4:48 PM Anthony Cowley <acowley at gmail.com> wrote:

> Yes, but a line-based format along the lines of:
>
> foo 1.2.3
> bar-baz 0.1.00
>
> Would be easier to parse with the usual shell tools.
>
> Anthony
>
> On Mar 26, 2015, at 9:41 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
> Is the idea that you'd be able to make a query such as:
>
> GET
> https://www.stackage.org/lts/1.14/build-plan?package=foo&package=bar&package=baz
>
> And get a result such as:
>
> [ {"name":"foo", "version":"1.2.3"}
> , ...
> ]
>
> ?
>
> On Thu, Mar 26, 2015 at 3:00 PM Anthony Cowley <acowley at gmail.com> wrote:
>
>>
>>
>>
>> On Mar 26, 2015, at 3:21 AM, Michael Snoyman <michael at snoyman.com> wrote:
>>
>>
>>
>> On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael at snoyman.com>
>>> wrote:
>>>
>>>
>>>
>>> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael at snoyman.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley at seas.upenn.edu>
>>>> wrote:
>>>>
>>>>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael at snoyman.com>
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <
>>>>> acowley at seas.upenn.edu>
>>>>> > wrote:
>>>>> >>
>>>>> >> The suggestion to use "cabal install --dependencies-only ..."
>>>>> instead
>>>>> >> of "cabal freeze" in that issue is really nicely presented. "cabal
>>>>> >> freeze" is close to the right thing, but it's just not as fully
>>>>> >> featured as "cabal install" (e.g. taking flags).
>>>>> >>
>>>>> >> As for Stackage, I think it would be helpful to cache the full build
>>>>> >> plans computed for each package in Stackage. This is most of the
>>>>> work
>>>>> >> my Nix tooling currently does, so it would be a big time saver.
>>>>> >>
>>>>> >>
>>>>> >
>>>>> > By "full build plans," do you mean the dist/setup-config file, or
>>>>> something
>>>>> > else? That file would be problematic since it's Cabal-library-version
>>>>> > specific IIRC. If you're looking for the full listing of deep
>>>>> dependencies
>>>>> > and versions, we can extract that from the .yaml file using the
>>>>> technique I
>>>>> > mentioned earlier.
>>>>> >
>>>>> > Michael
>>>>>
>>>>> Yes, I meant the full listing of deep dependencies.
>>>>>
>>>>>
>>>>>
>>>> I've put together a Gist with an executable that does what I described:
>>>>
>>>> https://gist.github.com/snoyberg/5b244331533fcb614523
>>>>
>>>> You give it three arguments on the command line:
>>>>
>>>> * LTS version, e.g. 1.14
>>>> * Name of package being checked
>>>> * true == only include dependencies of the library and executable,
>>>> anything else == include test and benchmark dependencies as well
>>>>
>>>> If that's useful, I can package that up and put it on Hackage.
>>>>
>>>> Michael
>>>>
>>>>
>>>> This is very helpfulness, thanks! There is a bootstrapping issue,
>>>> though, which is, I imagine, why both Mi?tek and I have been writing much
>>>> more bash than we'd like. But perhaps this becomes part of a
>>>> cabal-install-like bootstrap.sh script to get things going.
>>>>
>>>> Anthony
>>>>
>>>
>>> Oh, that's actually a great idea. What if we had a program that:
>>>
>>> 1. takes a set of packages that needs to be installed, and an LTS version
>>> 2. computes the dependency tree
>>> 3. writes out a shell script (possibly batch program?) to wget, tar xf,
>>> and runghc Setup.hs in the correct order to get all of those packages
>>> installed
>>>
>>> As you can tell from the program I just threw together, stackage-types
>>> supports this kind of thing pretty trivially.
>>>
>>> Michael
>>>
>>>
>>> Yes, that's what the Nix tooling does. The extra bits are building up
>>> package databases suitable for each build without copying files all over
>>> the place. That has the extra benefit of being able to reuse builds when
>>> the recipe is unchanged. It is definitely not hard, but getting the build
>>> plans from stackage in a portable way would be valuable.
>>>
>>> Anthony
>>>
>>
>> OK, I've updated the Gist so that it produces a shell script that will
>> install all necessary packages. It also has a nicer optparse-applicative
>> interface now.
>>
>> https://gist.github.com/snoyberg/5b244331533fcb614523
>>
>> One thing I didn't do here is add support for custom GHC package
>> databases. I assume you'll need that, but wasn't sure exactly how you're
>> doing that in Nix.
>>
>> If this is useful for you, I'll start a stackage-bootstrap repo, clean up
>> this code a bit, and we can continue improving it from there.
>>
>> Michael
>>
>>
>> Just having a URL from which to GET the build plan would be most useful.
>> As you say, the actual package building happens after DB creation, and that
>> requires knowing what to put in the DB.
>>
>> Anthony
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150326/93bf6efd/attachment-0001.html>

From michael at snoyman.com  Thu Mar 26 15:03:02 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 26 Mar 2015 15:03:02 +0000
Subject: [Haskell-cafe] Version constraints and cabal.config files
In-Reply-To: <CDC48714-2C0A-44B9-BB77-C1D65BB55F74@gmail.com>
References: <CAAJHNPDtG6L6gNGmY=arZdM_UWFdmQzueLAQH1pLA8VzEnsOtQ@mail.gmail.com>
 <D140E7E4-53AE-476A-835F-5B2A27E5DE90@bak.io>
 <CAAJHNPAJQYkjqQ1T6T4+v5EuFb92h8wP9yJT8EDuQucyLNhm+A@mail.gmail.com>
 <7D1B82EE-B31C-421E-9A12-FF1B4CCBAD28@bak.io>
 <CAAJHNPA9cDWk-EDYxLOKS77jHaZrvDZQ-yU+JMObPD1-5TEiZQ@mail.gmail.com>
 <B126AFC3-F97A-49F8-B833-667CBE66EBC3@bak.io>
 <CAKA2JgLdu+Zrfg6NKU-Y9WG86AKYstUL9J2YB1NC74wyKBOHrA@mail.gmail.com>
 <5E73356C-1973-4374-A706-A92359E96F08@bak.io>
 <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
 <05FE5722-5E2C-40A7-891C-18BC1DC3CA8C@bak.io>
 <CADch-tLMrJJG_u5Lt==dO8-FxCm3EzO+6W0ZdMuWQe5Finu=WA@mail.gmail.com>
 <CAKA2Jg+WXH7BTh=pOJduvaYn7RA6M0+PMG9HegRjFz6f72bfHA@mail.gmail.com>
 <CADch-tLtn0JTshORAgMi+mgEW+Ukxox5Hkzrk7s7eVqoJdJ_oQ@mail.gmail.com>
 <CAKA2JgK63uYfZ50-fiO53o1YCQcf80LHRoLg=K2NAsJKLOGJ+A@mail.gmail.com>
 <25FD20FD-AF3C-4122-857F-D3AD4FF4218E@gmail.com>
 <CAKA2JgLZp7H1_e+mJ2XYYnt2pACCbKfF7-g9z6vdUkezcV+8bQ@mail.gmail.com>
 <13826087-C1FC-4C71-B3E3-102188A05A2B@gmail.com>
 <CAKA2JgJK9n-eoesgFWzk93qF66b7t6qN03PZ7En_kJbUuvo6HA@mail.gmail.com>
 <97BBBDDB-1D2C-49E4-82F3-A2445B14DDF7@gmail.com>
 <CAKA2JgJLVNU=ciFAZYmA39XNrXkYfBVgimgU8Q90LzrycFg35A@mail.gmail.com>
 <15013C71-D09D-48C0-8954-F430DA251F5D@gmail.com>
 <CAKA2JgL6W7AFM6JZfmQvYp8+Hsj4zpTKZW8O1fVE=WSjd=jm0Q@mail.gmail.com>
 <CDC48714-2C0A-44B9-BB77-C1D65BB55F74@gmail.com>
Message-ID: <CAKA2JgLJF2Btv6LnOdmx4D4ihiOPi9ZRMz09GVF8Uu8s1sRPRQ@mail.gmail.com>

It's trivial for me to include them all, and equally trivial for me to call
out which ones are shipped with GHC somehow (such as an extra flag on that
line). I'll implement this currently to dump everything out without any
extra flag, and we can tweak it in the future.

On Thu, Mar 26, 2015 at 5:01 PM Anthony Cowley <acowley at gmail.com> wrote:

> This is a touch subtle. base can be left out, but other packages that ship
> with ghc and are usually found in the global package db should be included
> as they can be upgraded. This has knock on effects where a new version of
> the unix package means we have to rebuild the directory package with that
> updated dependency, for example. This is something I already handle, so I'd
> be happy to have everything included in the provided build plan. I'd need
> to think more about whether or not some packages can safely be totally left
> out, but I'm on the road at the moment and not terribly capable of thought.
>
> Anthony
>
>
> On Mar 26, 2015, at 10:50 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
> And do you want the information on the core packages (e.g., base,
> template-haskell, containers) as well, or should they be left out?
>
> On Thu, Mar 26, 2015 at 4:48 PM Anthony Cowley <acowley at gmail.com> wrote:
>
>> Yes, but a line-based format along the lines of:
>>
>> foo 1.2.3
>> bar-baz 0.1.00
>>
>> Would be easier to parse with the usual shell tools.
>>
>> Anthony
>>
>> On Mar 26, 2015, at 9:41 AM, Michael Snoyman <michael at snoyman.com> wrote:
>>
>> Is the idea that you'd be able to make a query such as:
>>
>> GET
>> https://www.stackage.org/lts/1.14/build-plan?package=foo&package=bar&package=baz
>>
>> And get a result such as:
>>
>> [ {"name":"foo", "version":"1.2.3"}
>> , ...
>> ]
>>
>> ?
>>
>> On Thu, Mar 26, 2015 at 3:00 PM Anthony Cowley <acowley at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Mar 26, 2015, at 3:21 AM, Michael Snoyman <michael at snoyman.com>
>>> wrote:
>>>
>>>
>>>
>>> On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael at snoyman.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael at snoyman.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley at seas.upenn.edu>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <
>>>>>> michael at snoyman.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <
>>>>>> acowley at seas.upenn.edu>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> The suggestion to use "cabal install --dependencies-only ..."
>>>>>> instead
>>>>>> >> of "cabal freeze" in that issue is really nicely presented. "cabal
>>>>>> >> freeze" is close to the right thing, but it's just not as fully
>>>>>> >> featured as "cabal install" (e.g. taking flags).
>>>>>> >>
>>>>>> >> As for Stackage, I think it would be helpful to cache the full
>>>>>> build
>>>>>> >> plans computed for each package in Stackage. This is most of the
>>>>>> work
>>>>>> >> my Nix tooling currently does, so it would be a big time saver.
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> > By "full build plans," do you mean the dist/setup-config file, or
>>>>>> something
>>>>>> > else? That file would be problematic since it's
>>>>>> Cabal-library-version
>>>>>> > specific IIRC. If you're looking for the full listing of deep
>>>>>> dependencies
>>>>>> > and versions, we can extract that from the .yaml file using the
>>>>>> technique I
>>>>>> > mentioned earlier.
>>>>>> >
>>>>>> > Michael
>>>>>>
>>>>>> Yes, I meant the full listing of deep dependencies.
>>>>>>
>>>>>>
>>>>>>
>>>>> I've put together a Gist with an executable that does what I described:
>>>>>
>>>>> https://gist.github.com/snoyberg/5b244331533fcb614523
>>>>>
>>>>> You give it three arguments on the command line:
>>>>>
>>>>> * LTS version, e.g. 1.14
>>>>> * Name of package being checked
>>>>> * true == only include dependencies of the library and executable,
>>>>> anything else == include test and benchmark dependencies as well
>>>>>
>>>>> If that's useful, I can package that up and put it on Hackage.
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>> This is very helpfulness, thanks! There is a bootstrapping issue,
>>>>> though, which is, I imagine, why both Mi?tek and I have been writing much
>>>>> more bash than we'd like. But perhaps this becomes part of a
>>>>> cabal-install-like bootstrap.sh script to get things going.
>>>>>
>>>>> Anthony
>>>>>
>>>>
>>>> Oh, that's actually a great idea. What if we had a program that:
>>>>
>>>> 1. takes a set of packages that needs to be installed, and an LTS
>>>> version
>>>> 2. computes the dependency tree
>>>> 3. writes out a shell script (possibly batch program?) to wget, tar xf,
>>>> and runghc Setup.hs in the correct order to get all of those packages
>>>> installed
>>>>
>>>> As you can tell from the program I just threw together, stackage-types
>>>> supports this kind of thing pretty trivially.
>>>>
>>>> Michael
>>>>
>>>>
>>>> Yes, that's what the Nix tooling does. The extra bits are building up
>>>> package databases suitable for each build without copying files all over
>>>> the place. That has the extra benefit of being able to reuse builds when
>>>> the recipe is unchanged. It is definitely not hard, but getting the build
>>>> plans from stackage in a portable way would be valuable.
>>>>
>>>> Anthony
>>>>
>>>
>>> OK, I've updated the Gist so that it produces a shell script that will
>>> install all necessary packages. It also has a nicer optparse-applicative
>>> interface now.
>>>
>>> https://gist.github.com/snoyberg/5b244331533fcb614523
>>>
>>> One thing I didn't do here is add support for custom GHC package
>>> databases. I assume you'll need that, but wasn't sure exactly how you're
>>> doing that in Nix.
>>>
>>> If this is useful for you, I'll start a stackage-bootstrap repo, clean
>>> up this code a bit, and we can continue improving it from there.
>>>
>>> Michael
>>>
>>>
>>> Just having a URL from which to GET the build plan would be most useful.
>>> As you say, the actual package building happens after DB creation, and that
>>> requires knowing what to put in the DB.
>>>
>>> Anthony
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150326/453c7101/attachment.html>

From michael at snoyman.com  Thu Mar 26 15:49:15 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 26 Mar 2015 15:49:15 +0000
Subject: [Haskell-cafe] Version constraints and cabal.config files
In-Reply-To: <CAKA2JgLJF2Btv6LnOdmx4D4ihiOPi9ZRMz09GVF8Uu8s1sRPRQ@mail.gmail.com>
References: <CAAJHNPDtG6L6gNGmY=arZdM_UWFdmQzueLAQH1pLA8VzEnsOtQ@mail.gmail.com>
 <D140E7E4-53AE-476A-835F-5B2A27E5DE90@bak.io>
 <CAAJHNPAJQYkjqQ1T6T4+v5EuFb92h8wP9yJT8EDuQucyLNhm+A@mail.gmail.com>
 <7D1B82EE-B31C-421E-9A12-FF1B4CCBAD28@bak.io>
 <CAAJHNPA9cDWk-EDYxLOKS77jHaZrvDZQ-yU+JMObPD1-5TEiZQ@mail.gmail.com>
 <B126AFC3-F97A-49F8-B833-667CBE66EBC3@bak.io>
 <CAKA2JgLdu+Zrfg6NKU-Y9WG86AKYstUL9J2YB1NC74wyKBOHrA@mail.gmail.com>
 <5E73356C-1973-4374-A706-A92359E96F08@bak.io>
 <CAKA2Jg+x0Ne9=pN_RYk+eJH9evZM1RmFOvEUivmaj-Ehn7tB3g@mail.gmail.com>
 <05FE5722-5E2C-40A7-891C-18BC1DC3CA8C@bak.io>
 <CADch-tLMrJJG_u5Lt==dO8-FxCm3EzO+6W0ZdMuWQe5Finu=WA@mail.gmail.com>
 <CAKA2Jg+WXH7BTh=pOJduvaYn7RA6M0+PMG9HegRjFz6f72bfHA@mail.gmail.com>
 <CADch-tLtn0JTshORAgMi+mgEW+Ukxox5Hkzrk7s7eVqoJdJ_oQ@mail.gmail.com>
 <CAKA2JgK63uYfZ50-fiO53o1YCQcf80LHRoLg=K2NAsJKLOGJ+A@mail.gmail.com>
 <25FD20FD-AF3C-4122-857F-D3AD4FF4218E@gmail.com>
 <CAKA2JgLZp7H1_e+mJ2XYYnt2pACCbKfF7-g9z6vdUkezcV+8bQ@mail.gmail.com>
 <13826087-C1FC-4C71-B3E3-102188A05A2B@gmail.com>
 <CAKA2JgJK9n-eoesgFWzk93qF66b7t6qN03PZ7En_kJbUuvo6HA@mail.gmail.com>
 <97BBBDDB-1D2C-49E4-82F3-A2445B14DDF7@gmail.com>
 <CAKA2JgJLVNU=ciFAZYmA39XNrXkYfBVgimgU8Q90LzrycFg35A@mail.gmail.com>
 <15013C71-D09D-48C0-8954-F430DA251F5D@gmail.com>
 <CAKA2JgL6W7AFM6JZfmQvYp8+Hsj4zpTKZW8O1fVE=WSjd=jm0Q@mail.gmail.com>
 <CDC48714-2C0A-44B9-BB77-C1D65BB55F74@gmail.com>
 <CAKA2JgLJF2Btv6LnOdmx4D4ihiOPi9ZRMz09GVF8Uu8s1sRPRQ@mail.gmail.com>
Message-ID: <CAKA2Jg+SSzpgF-syRp=0y2MYLKpPGaFi_4pzq3pCPHHW1Y9HiQ@mail.gmail.com>

OK, should be working now:
http://www.stackage.org/lts/build-plan?package=warp

On Thu, Mar 26, 2015 at 5:03 PM Michael Snoyman <michael at snoyman.com> wrote:

> It's trivial for me to include them all, and equally trivial for me to
> call out which ones are shipped with GHC somehow (such as an extra flag on
> that line). I'll implement this currently to dump everything out without
> any extra flag, and we can tweak it in the future.
>
> On Thu, Mar 26, 2015 at 5:01 PM Anthony Cowley <acowley at gmail.com> wrote:
>
>> This is a touch subtle. base can be left out, but other packages that
>> ship with ghc and are usually found in the global package db should be
>> included as they can be upgraded. This has knock on effects where a new
>> version of the unix package means we have to rebuild the directory package
>> with that updated dependency, for example. This is something I already
>> handle, so I'd be happy to have everything included in the provided build
>> plan. I'd need to think more about whether or not some packages can safely
>> be totally left out, but I'm on the road at the moment and not terribly
>> capable of thought.
>>
>> Anthony
>>
>>
>> On Mar 26, 2015, at 10:50 AM, Michael Snoyman <michael at snoyman.com>
>> wrote:
>>
>> And do you want the information on the core packages (e.g., base,
>> template-haskell, containers) as well, or should they be left out?
>>
>> On Thu, Mar 26, 2015 at 4:48 PM Anthony Cowley <acowley at gmail.com> wrote:
>>
>>> Yes, but a line-based format along the lines of:
>>>
>>> foo 1.2.3
>>> bar-baz 0.1.00
>>>
>>> Would be easier to parse with the usual shell tools.
>>>
>>> Anthony
>>>
>>> On Mar 26, 2015, at 9:41 AM, Michael Snoyman <michael at snoyman.com>
>>> wrote:
>>>
>>> Is the idea that you'd be able to make a query such as:
>>>
>>> GET https://www.stackage.org/lts/1.14/build-plan?package=foo&
>>> package=bar&package=baz
>>>
>>> And get a result such as:
>>>
>>> [ {"name":"foo", "version":"1.2.3"}
>>> , ...
>>> ]
>>>
>>> ?
>>>
>>> On Thu, Mar 26, 2015 at 3:00 PM Anthony Cowley <acowley at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Mar 26, 2015, at 3:21 AM, Michael Snoyman <michael at snoyman.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael at snoyman.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael at snoyman.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <
>>>>>> acowley at seas.upenn.edu> wrote:
>>>>>>
>>>>>>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <
>>>>>>> michael at snoyman.com> wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <
>>>>>>> acowley at seas.upenn.edu>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> The suggestion to use "cabal install --dependencies-only ..."
>>>>>>> instead
>>>>>>> >> of "cabal freeze" in that issue is really nicely presented. "cabal
>>>>>>> >> freeze" is close to the right thing, but it's just not as fully
>>>>>>> >> featured as "cabal install" (e.g. taking flags).
>>>>>>> >>
>>>>>>> >> As for Stackage, I think it would be helpful to cache the full
>>>>>>> build
>>>>>>> >> plans computed for each package in Stackage. This is most of the
>>>>>>> work
>>>>>>> >> my Nix tooling currently does, so it would be a big time saver.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >
>>>>>>> > By "full build plans," do you mean the dist/setup-config file, or
>>>>>>> something
>>>>>>> > else? That file would be problematic since it's
>>>>>>> Cabal-library-version
>>>>>>> > specific IIRC. If you're looking for the full listing of deep
>>>>>>> dependencies
>>>>>>> > and versions, we can extract that from the .yaml file using the
>>>>>>> technique I
>>>>>>> > mentioned earlier.
>>>>>>> >
>>>>>>> > Michael
>>>>>>>
>>>>>>> Yes, I meant the full listing of deep dependencies.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I've put together a Gist with an executable that does what I
>>>>>> described:
>>>>>>
>>>>>> https://gist.github.com/snoyberg/5b244331533fcb614523
>>>>>>
>>>>>> You give it three arguments on the command line:
>>>>>>
>>>>>> * LTS version, e.g. 1.14
>>>>>> * Name of package being checked
>>>>>> * true == only include dependencies of the library and executable,
>>>>>> anything else == include test and benchmark dependencies as well
>>>>>>
>>>>>> If that's useful, I can package that up and put it on Hackage.
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> This is very helpfulness, thanks! There is a bootstrapping issue,
>>>>>> though, which is, I imagine, why both Mi?tek and I have been writing much
>>>>>> more bash than we'd like. But perhaps this becomes part of a
>>>>>> cabal-install-like bootstrap.sh script to get things going.
>>>>>>
>>>>>> Anthony
>>>>>>
>>>>>
>>>>> Oh, that's actually a great idea. What if we had a program that:
>>>>>
>>>>> 1. takes a set of packages that needs to be installed, and an LTS
>>>>> version
>>>>> 2. computes the dependency tree
>>>>> 3. writes out a shell script (possibly batch program?) to wget, tar
>>>>> xf, and runghc Setup.hs in the correct order to get all of those packages
>>>>> installed
>>>>>
>>>>> As you can tell from the program I just threw together, stackage-types
>>>>> supports this kind of thing pretty trivially.
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>> Yes, that's what the Nix tooling does. The extra bits are building up
>>>>> package databases suitable for each build without copying files all over
>>>>> the place. That has the extra benefit of being able to reuse builds when
>>>>> the recipe is unchanged. It is definitely not hard, but getting the build
>>>>> plans from stackage in a portable way would be valuable.
>>>>>
>>>>> Anthony
>>>>>
>>>>
>>>> OK, I've updated the Gist so that it produces a shell script that will
>>>> install all necessary packages. It also has a nicer optparse-applicative
>>>> interface now.
>>>>
>>>> https://gist.github.com/snoyberg/5b244331533fcb614523
>>>>
>>>> One thing I didn't do here is add support for custom GHC package
>>>> databases. I assume you'll need that, but wasn't sure exactly how you're
>>>> doing that in Nix.
>>>>
>>>> If this is useful for you, I'll start a stackage-bootstrap repo, clean
>>>> up this code a bit, and we can continue improving it from there.
>>>>
>>>> Michael
>>>>
>>>>
>>>> Just having a URL from which to GET the build plan would be most
>>>> useful. As you say, the actual package building happens after DB creation,
>>>> and that requires knowing what to put in the DB.
>>>>
>>>> Anthony
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150326/5be33330/attachment-0001.html>

From bob at redivi.com  Sun Mar 29 05:55:31 2015
From: bob at redivi.com (Bob Ippolito)
Date: Sat, 28 Mar 2015 22:55:31 -0700
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <0754B7EF-BA0E-4802-9906-203BA5594281@bak.io>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
 <CAK-tuPaay7R+6qJ1k8cNv1m-ZQOEVyL2mDabTCBDhyRRYntifA@mail.gmail.com>
 <CANQO64LQfQFtYkX5yP9v02fOKawFrr9NKxF-gsK5UqXsjaEzLw@mail.gmail.com>
 <CAJCpNrp3eNkwCvx4vG_KSe2QbmQpapCiPVzCZPHnnWd1+Xq3UA@mail.gmail.com>
 <0754B7EF-BA0E-4802-9906-203BA5594281@bak.io>
Message-ID: <CACwMPm_1wddcr2XCAjcXnQarmifhwpv1ooTiTqDkTsrQQcUdgw@mail.gmail.com>

Is it possible to download and use these binary builds without halcyon? On
Mac it's a bit hard to set up halcyon due to the bash 4 requirement, and
there are no official cabal-install binaries of the latest releases for Mac
(latest is 1.22.0.0). I took a look at the halcyon source but wasn't able
to quickly figure out what the URL scheme for cabal-install on public
storage would be, I'm guessing it's just included in a larger sandbox
rather than distributed on its own?

On Sun, Mar 22, 2015 at 5:58 PM, Mi?tek Bak <mietek at bak.io> wrote:

> Thanks, Ryan.  I?ve since added binaries of 1.22.2.0 for:
>
> - Gentoo Linux (x86_64)
> - Slackware 14.1 (x86_64)
>
> I should note this is in addition to binaries of 1.22.0.0 and 1.20.0.3,
> also available for all of the previously mentioned platforms.
>
> Other versions can also be selected by the user to be bootstrapped and
> automatically cached:
> https://halcyon.sh/reference/#halcyon_cabal_version
>
>
> --
> Mi?tek
> https://mietek.io
>
>
>
>
> On 2015-03-22, at 08:38, Ryan Thomas <ryan at ryant.org> wrote:
>
> > Agreed, I'd love to have the CI tools build all of the release artifacts.
> >
> > Mi?tek: I'll update the downloads page with a link to halcyon for
> > those platforms.
> >
> > Cheers,
> >
> > ryan
> >
> > On 22 March 2015 at 08:36, Chris Wong <lambda.fairy at gmail.com> wrote:
> >> On Sun, Mar 22, 2015 at 9:19 PM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
> >>> On Sat, Mar 21, 2015 at 10:34 PM, Ryan Thomas <ryan at ryant.org> wrote:
> >>>>
> >>>> - The Windows/OSX/Linux specific binaries need to be built and updated
> >>>> on the download page; Johan I will probably need some guidance on the
> >>>> process for this.
> >>>
> >>>
> >>> There's not much of a process I'm afraid. I usually send out and email
> to
> >>> cabal-devel@, asking for people to build binaries and send them to
> me. I
> >>> build some myself. Ideally at least one binary would be built by the
> release
> >>> process itself (and the others perhaps by build bots).
> >>
> >> AppVeyor and Travis CI support Windows and OS X respectively; perhaps
> >> we can arrange something with those.
> >>
> >>> _______________________________________________
> >>> cabal-devel mailing list
> >>> cabal-devel at haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> >>>
> >>
> >> --
> >> https://lambda.xyz
> > _______________________________________________
> > cabal-devel mailing list
> > cabal-devel at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150328/c2569543/attachment.html>

From mietek at bak.io  Sun Mar 29 14:14:01 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Sun, 29 Mar 2015 15:14:01 +0100
Subject: Cabal and cabal-install minor release (1.22.2.0)
In-Reply-To: <CACwMPm_1wddcr2XCAjcXnQarmifhwpv1ooTiTqDkTsrQQcUdgw@mail.gmail.com>
References: <CAJCpNrrBZMvpmvxfhxJToheyLoZCEm_t01AWPayuduO0+5VB8w@mail.gmail.com>
 <CAK-tuPaay7R+6qJ1k8cNv1m-ZQOEVyL2mDabTCBDhyRRYntifA@mail.gmail.com>
 <CANQO64LQfQFtYkX5yP9v02fOKawFrr9NKxF-gsK5UqXsjaEzLw@mail.gmail.com>
 <CAJCpNrp3eNkwCvx4vG_KSe2QbmQpapCiPVzCZPHnnWd1+Xq3UA@mail.gmail.com>
 <0754B7EF-BA0E-4802-9906-203BA5594281@bak.io>
 <CACwMPm_1wddcr2XCAjcXnQarmifhwpv1ooTiTqDkTsrQQcUdgw@mail.gmail.com>
Message-ID: <294D41B5-7D15-4859-93ED-36C2DE77344B@bak.io>

Yes, it is possible, and no, sandboxes are kept in separate archives.

Each of the following archives contains the cabal-install executable only, bootstrapped using GHC 7.8.4, located in `./bin/cabal`.

Bootstrapped on OS X 10.10:
https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.0.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.1.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.3.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.5.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.20.0.6.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.22.0.0.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.22.0.1.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.10-x86_64/halcyon-cabal-1.22.2.0.tar.gz

Bootstrapped on OS X 10.9:
https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.0.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.1.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.3.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.5.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.20.0.6.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.22.0.0.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.22.0.1.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.9-x86_64/halcyon-cabal-1.22.2.0.tar.gz

Bootstrapped on OS X 10.8:
https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.0.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.1.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.3.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.5.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.20.0.6.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.22.0.0.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.22.0.1.tar.gz
https://halcyon.global.ssl.fastly.net/osx-10.8-x86_64/halcyon-cabal-1.22.2.0.tar.gz

Note it?s also possible to browse Halcyon public storage:
https://halcyon.global.ssl.fastly.net/


-- 
Mi?tek
https://mietek.io




On 2015-03-29, at 06:55, Bob Ippolito <bob at redivi.com> wrote:

> Is it possible to download and use these binary builds without halcyon? On Mac it's a bit hard to set up halcyon due to the bash 4 requirement, and there are no official cabal-install binaries of the latest releases for Mac (latest is 1.22.0.0). I took a look at the halcyon source but wasn't able to quickly figure out what the URL scheme for cabal-install on public storage would be, I'm guessing it's just included in a larger sandbox rather than distributed on its own?
> 
> On Sun, Mar 22, 2015 at 5:58 PM, Mi?tek Bak <mietek at bak.io> wrote:
> Thanks, Ryan.  I?ve since added binaries of 1.22.2.0 for:
> 
> - Gentoo Linux (x86_64)
> - Slackware 14.1 (x86_64)
> 
> I should note this is in addition to binaries of 1.22.0.0 and 1.20.0.3, also available for all of the previously mentioned platforms.
> 
> Other versions can also be selected by the user to be bootstrapped and automatically cached:
> https://halcyon.sh/reference/#halcyon_cabal_version
> 
> 
> --
> Mi?tek
> https://mietek.io
> 
> 
> 
> 
> On 2015-03-22, at 08:38, Ryan Thomas <ryan at ryant.org> wrote:
> 
> > Agreed, I'd love to have the CI tools build all of the release artifacts.
> >
> > Mi?tek: I'll update the downloads page with a link to halcyon for
> > those platforms.
> >
> > Cheers,
> >
> > ryan
> >
> > On 22 March 2015 at 08:36, Chris Wong <lambda.fairy at gmail.com> wrote:
> >> On Sun, Mar 22, 2015 at 9:19 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> >>> On Sat, Mar 21, 2015 at 10:34 PM, Ryan Thomas <ryan at ryant.org> wrote:
> >>>>
> >>>> - The Windows/OSX/Linux specific binaries need to be built and updated
> >>>> on the download page; Johan I will probably need some guidance on the
> >>>> process for this.
> >>>
> >>>
> >>> There's not much of a process I'm afraid. I usually send out and email to
> >>> cabal-devel@, asking for people to build binaries and send them to me. I
> >>> build some myself. Ideally at least one binary would be built by the release
> >>> process itself (and the others perhaps by build bots).
> >>
> >> AppVeyor and Travis CI support Windows and OS X respectively; perhaps
> >> we can arrange something with those.
> >>
> >>> _______________________________________________
> >>> cabal-devel mailing list
> >>> cabal-devel at haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> >>>
> >>
> >> --
> >> https://lambda.xyz
> > _______________________________________________
> > cabal-devel mailing list
> > cabal-devel at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> 
> 
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150329/47363645/attachment.bin>