March 2015 - cabal-devel

Cabal and simultaneous installations of the same package
by Simon Peyton Jones 29 Aug '15

29 Aug '15

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

8 17

Cabal and cabal-install minor release (1.22.2.0)
by Ryan Thomas 06 May '15

06 May '15

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

6 12

inactive issues
by lennart spitzner 22 Apr '15

22 Apr '15

hi, i noticed today's run at the closing "inactive" issues on the tracker. i would like to to ask an innocent question: what exactly is the benefit of this action? (i disclose that it seems to me that valid, if inactive, issues are being closed, which i do not like. but before complaining, i want to know the counter-arguments). Lennart

6 10

Re: [Haskell-cafe] Version constraints and cabal.config files
by Michael Snoyman 27 Mar '15

27 Mar '15

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(a)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(a)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(a)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(a)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&packag… >> >> And get a result such as: >> >> [ {"name":"foo", "version":"1.2.3"} >> , ... >> ] >> >> ? >> >> On Thu, Mar 26, 2015 at 3:00 PM Anthony Cowley <acowley(a)gmail.com> wrote: >> >>> >>> >>> >>> On Mar 26, 2015, at 3:21 AM, Michael Snoyman <michael(a)snoyman.com> >>> wrote: >>> >>> >>> >>> On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> >>>> On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael(a)snoyman.com> >>>> wrote: >>>> >>>> >>>> >>>> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael(a)snoyman.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley(a)seas.upenn.edu> >>>>> wrote: >>>>> >>>>>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman < >>>>>> michael(a)snoyman.com> wrote: >>>>>> > >>>>>> > >>>>>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley < >>>>>> acowley(a)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 >>> >>

1 1

Re: [Haskell-cafe] Version constraints and cabal.config files
by Michael Snoyman 27 Mar '15

27 Mar '15

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(a)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(a)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&packag… > > And get a result such as: > > [ {"name":"foo", "version":"1.2.3"} > , ... > ] > > ? > > On Thu, Mar 26, 2015 at 3:00 PM Anthony Cowley <acowley(a)gmail.com> wrote: > >> >> >> >> On Mar 26, 2015, at 3:21 AM, Michael Snoyman <michael(a)snoyman.com> wrote: >> >> >> >> On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley(a)gmail.com> wrote: >> >>> >>> >>> >>> On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael(a)snoyman.com> >>> wrote: >>> >>> >>> >>> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael(a)snoyman.com> >>>> wrote: >>>> >>>> >>>> >>>> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley(a)seas.upenn.edu> >>>> wrote: >>>> >>>>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael(a)snoyman.com> >>>>> wrote: >>>>> > >>>>> > >>>>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley < >>>>> acowley(a)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 >> >

1 0

Re: [Haskell-cafe] Version constraints and cabal.config files
by Michael Snoyman 26 Mar '15

26 Mar '15

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&packag… And get a result such as: [ {"name":"foo", "version":"1.2.3"} , ... ] ? On Thu, Mar 26, 2015 at 3:00 PM Anthony Cowley <acowley(a)gmail.com> wrote: > > > > On Mar 26, 2015, at 3:21 AM, Michael Snoyman <michael(a)snoyman.com> wrote: > > > > On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley(a)gmail.com> wrote: > >> >> >> >> On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael(a)snoyman.com> >> wrote: >> >> >> >> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley(a)gmail.com> wrote: >> >>> >>> >>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael(a)snoyman.com> >>> wrote: >>> >>> >>> >>> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley(a)seas.upenn.edu> >>> wrote: >>> >>>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael(a)snoyman.com> >>>> wrote: >>>> > >>>> > >>>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley < >>>> acowley(a)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 >

1 0

Re: [Haskell-cafe] Version constraints and cabal.config files
by Michael Snoyman 26 Mar '15

26 Mar '15

On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley(a)gmail.com> wrote: > > > > On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael(a)snoyman.com> wrote: > > > > On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley(a)gmail.com> wrote: > >> >> >> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael(a)snoyman.com> >> wrote: >> >> >> >> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley(a)seas.upenn.edu> >> wrote: >> >>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael(a)snoyman.com> >>> wrote: >>> > >>> > >>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <acowley(a)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

1 0

Re: [Haskell-cafe] Version constraints and cabal.config files
by Michael Snoyman 26 Mar '15

26 Mar '15

On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley(a)gmail.com> wrote: > > > On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael(a)snoyman.com> wrote: > > > > On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley(a)seas.upenn.edu> > wrote: > >> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael(a)snoyman.com> >> wrote: >> > >> > >> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <acowley(a)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

1 0

Re: [Haskell-cafe] Version constraints and cabal.config files
by Michael Snoyman 26 Mar '15

26 Mar '15

On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley(a)seas.upenn.edu> wrote: > On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael(a)snoyman.com> > wrote: > > > > > > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <acowley(a)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

1 0

Re: [Haskell-cafe] Version constraints and cabal.config files
by Michael Snoyman 26 Mar '15

26 Mar '15

On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <acowley(a)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

1 0