- cabal-devel - Haskell.org

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

25 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

Re: Version constraints and cabal.config files
by Miëtek Bak 25 Mar '15

25 Mar '15

On 2015-03-25, at 12:16, Michael Snoyman <michael(a)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

1 0

hackage statistics
by Meng Wang 24 Mar '15

24 Mar '15

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

1 0

Re: wither the Platform
by Miëtek Bak 23 Mar '15

23 Mar '15

On 2015-03-22, at 15:59, Michael Snoyman <michael(a)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

1 0

Cabal webpage on haskell.org
by Miëtek Bak 23 Mar '15

23 Mar '15

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

4 6

Ryan Thomas is the new release manager
by Johan Tibell 21 Mar '15

21 Mar '15

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

3 2

Re: Please review: new wiki page with release instructions
by Mikhail Glushenkov 19 Mar '15

19 Mar '15

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

1 0

Re: Please review: new wiki page with release instructions
by Johan Tibell 19 Mar '15

19 Mar '15

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(a)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/7c132c02436fadaa70674bbfe38b21a67… > > Cheers, > hvr >

1 0

Please review: new wiki page with release instructions
by Johan Tibell 19 Mar '15

19 Mar '15

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

5 7