- cabal-devel - Haskell.org

Installation error of libxml-sax
by Peng Yu 24 Apr '15

24 Apr '15

I got the following errors. Does anybody know how to fix it? Thanks. ~$ cabal install libxml-sax Resolving dependencies... Configuring libxml-sax-0.7.5... Failed to install libxml-sax-0.7.5 Last 10 lines of the build log ( /Users/pengy/.cabal/logs/libxml-sax-0.7.5.log ): Configuring libxml-sax-0.7.5... setup-Cabal-1.18.1.4-x86_64-osx-ghc-7.8.3: The program pkg-config version >=0.9.0 is required but it could not be found. cabal: Error: some packages failed to install: libxml-sax-0.7.5 failed during the configure step. The exception was: ExitFailure 1 -- Regards, Peng

2 1

inactive issues
by lennart spitzner 21 Apr '15

21 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

New minor 1.22 release?
by Luite Stegeman 20 Apr '15

20 Apr '15

Hi all, Unfortunately GHC 7.10.1 shipped with a Cabal library that handles ghcjs-pkg version numbers wrong, making it unusable to boot GHCJS. I'd like 7.10.2 to ship with a working version (7.10.2 itself also contains an important bugfix for GHCJS), which would require a new minor version release. Can we do one soon? Let me know if I can do anything to help! luite

2 4

An Easy Solution to PVP Bounds and Cabal Hell
by Gershom B 01 Apr '15

01 Apr '15

Recently there has been some discussion about how we can fix the problem of “Cabal Hell”. Some people advocate restrictive upper bounds, to prevent packages from being broken by new updates. Some other people point out that too-restrictive bounds can lead to bad install plans, since some packages might want newer versions of some dependencies, and others older versions. Still other people say that we can _retroactively_ fix upper bounds (in either direction) by modifying cabal files using the new features in Hackage. Some people think this is a terrible idea because it looks like we are mutating things, and this confuses hashes. In turn, these people support either nix or a nix-like approach by which packages have hashes that encompass the full versions of all their transitive dependencies. With that in hand, we can cache builds and mix-and-match to build the precise environment we want for each package while reducing redundant computation. However, the cache of all the various binary combinations may still grow large! And none of this fully begins to address the dreaded “diamond dependency” problem. Here is a chart of some such solutions: http://www.well-typed.com/blog/aux/images/cabal-hell/cabal-hell-solutions.p… One way to look at a particular build is in an n-dimensional state space (of the Hilbert sort) determined by all its dependencies, not least the compiler itself. The solver acts as a particle traversing this space. But this description is too simple. Our state of dependencies and constraints itself varies and grows over time. So another approach is to think of the dependencies as a transitive graph, where each node may vary along a time axis, and as they slide along the axis, this in turn affects their children. We now have not just one Hilbert space, but a collection of them related by branching trees as authors locally modify the dependencies of their packages. If we keep this simple model in mind, it is easy to see why everyone is always having these debates. Some people want to fix the graph, and others want to simplify it. Some people want an immutable store, and some people want to rebase. But we can’t “really” rebase in our current model. Bearing in mind our model of a space-time continuum of hackage dependences, the solution emerges — enforce immutability, but allow retroactive mutation. For instance, suppose Fred tries to install package Foo on Friday evening, but discovers that it depends on version 1.0 of Bar (released the previous Friday) that in turn depends on version 0.5 of Baz but Foo also depends on version 0.8 of Baz. So Fred branches Bar and changes the dependency, which in turn informs Betty, that there is also a 1.0 of Bar with different dependencies and we have forked our package timeline. On getting this message on Monday, Betty can merge by pushing with --force-rewrites and this goes back in the timeline and makes it so that Baz retroactively had the right dependencies and now Fred, as of the previous Friday, no longer has this problem. (That way he still has the weekend). Now the failed build is cut off temporarily into a cycle in the package timeline that is disconnected from the rewrite. We stash it with “hackage stash” until Monday at which time the dependency graph is 100 percent equalized and primed for new patches. At this point we unstash Foo as of Friday and it is replaced by the Foo from the new timeline. Friday Fred needs to remain stashed lest he run into himself. The longer he can be avoided by his Monday self the better. Future work could include bots which automate pruning of artifacts from redundant branches. If this description was too abrupt, here is a diagram with a fuller description of the workflow: http://bit.ly/15IIGac I know there are some new ideas to take in here, and there is a little technical work necessary to make it feasible, but in my opinion if you can understand the current cabal situation, and you can understand how git and darcs work, then you should be able to understand this too. Hopefully by this time next year, we’ll be able to say that our problems with cabal have been truly wiped from our collective memory. HTH, HAND. Gershom

3 2

Mentors and thoughts on a GSoC proposal?
by Gershom B 01 Apr '15

01 Apr '15

Hi all! We have the following GSoC proposal submitted to us: https://gist.github.com/fugyk/37510958b52589737274 Is there anyone on the cabal-devel list who would like to join as a mentor either to comment on this proposal, or feels up to mentoring this proposal (if we are to accept it, it will need a mentor with good familiarity with cabal internals)? Please let me know, or register on google melange and establish a connection to haskell.org if so. Cheers, Gershom

1 0

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

26 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 26 Mar '15

26 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 25 Mar '15

25 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