Any ways to test a GHC build against large set of packages (including test suites)?

Ömer Sinan Ağacan

6 Aug 2018 6 Aug '18

3:40 a.m.

Hi, I'd like to test some GHC builds + some compile and runtime flag combinations against a large set of packages by building them and running test suites. For this I need - A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better) I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details. Thanks, Ömer

Show replies by date

Ben Gamari

6 Aug 6 Aug

9:44 a.m.

Ömer Sinan Ağacan writes:

...

Hi,

I'd like to test some GHC builds + some compile and runtime flag combinations against a large set of packages by building them and running test suites. For this I need

- A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better)

I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details.

You are probably remembering head.hackage [1], which has both nix and non-nix tooling. A few of us have been trying to bring it up-to-date with GHC 8.6. I suspect the changes in HEAD are small enough that it will work with newer compilers as well. Cheers, - Ben [1] https://github.com/hvr/head.hackage

Manuel M T Chakravarty

7 Aug 7 Aug

11:15 a.m.

Hi Ömer, This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at https://github.com/tweag/stackage-head and also the blog post from when the first version went live: https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html Cheers, Manuel

...

Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan :

Hi,

I'd like to test some GHC builds + some compile and runtime flag combinations against a large set of packages by building them and running test suites. For this I need

- A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better)

I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details.

Thanks,

Ömer _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ömer Sinan Ağacan

4:28 p.m.

Thanks for both suggestions. I'll try both and see which one works better. Ömer Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15 tarihinde şunu yazdı:

...

Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers, Manuel

...
Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan :

Hi,

I'd like to test some GHC builds + some compile and runtime flag combinations against a large set of packages by building them and running test suites. For this I need

- A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better)

I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details.

Thanks,

Ömer _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ömer Sinan Ağacan

9 Aug 9 Aug

6:20 a.m.

Hi Manuel, I'm trying stackage-head. I'm following the steps for the scheduled build in .circleci/config.yml. So far steps I took: - Installed ghc-head (from [1]) to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head (with -fdev) from git repos, using stack. - export BUILD_PLAN=nightly-2018-07-30 (from config.yml) - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml Now I'm doing - ./.local/bin/stackage-head already-seen --target $BUILD_PLAN --ghc-metadata metadata.json --outdir build-reports but it's failing with The combination of target and commit is new to me Any ideas what I'm doing wrong? Thanks [1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... Ömer Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28 tarihinde şunu yazdı:

...

Thanks for both suggestions. I'll try both and see which one works better.

Ömer

Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15 tarihinde şunu yazdı:

...
Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers, Manuel

...
Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan :

Hi,

I'd like to test some GHC builds + some compile and runtime flag combinations against a large set of packages by building them and running test suites. For this I need

- A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better)

I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details.

Thanks,

Ömer _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ömer Sinan Ağacan

7:45 a.m.

Ah, I now realize that that command is supposed to print that output. I'll continue following the steps and keep you updated if I get stuck again. Ömer Ömer Sinan Ağacan , 9 Ağu 2018 Per, 13:20 tarihinde şunu yazdı:

...

Hi Manuel,

I'm trying stackage-head. I'm following the steps for the scheduled build in .circleci/config.yml. So far steps I took:

- Installed ghc-head (from [1]) to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head (with -fdev) from git repos, using stack. - export BUILD_PLAN=nightly-2018-07-30 (from config.yml) - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml

Now I'm doing

- ./.local/bin/stackage-head already-seen --target $BUILD_PLAN --ghc-metadata metadata.json --outdir build-reports

but it's failing with

The combination of target and commit is new to me

Any ideas what I'm doing wrong?

Thanks

[1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/...

Ömer

Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28 tarihinde şunu yazdı:

...
Thanks for both suggestions. I'll try both and see which one works better.

Ömer

Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15 tarihinde şunu yazdı:

...
Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers, Manuel

...
Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan :

Hi,

I'd like to test some GHC builds + some compile and runtime flag combinations against a large set of packages by building them and running test suites. For this I need

- A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better)

I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details.

Thanks,

Ömer _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ömer Sinan Ağacan

10 Aug 10 Aug

4:39 a.m.

Hi, This is working great, I just generated my first report. One problem is stm-2.4 doesn't compile with GHC HEAD, we need stm-2.5.0.0. But that's not published on Hackage yet, and latest nightly still uses stm-2.4.5.0. I wonder if there's anything that can be done about this. Apparently stm blocks 82 packages (I don't know if that's counting transitively or just packages that are directly blocked by stm). Any ideas about this? Ömer Ömer Sinan Ağacan , 9 Ağu 2018 Per, 14:45 tarihinde şunu yazdı:

...

Ah, I now realize that that command is supposed to print that output. I'll continue following the steps and keep you updated if I get stuck again.

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 13:20 tarihinde şunu yazdı:

...
Hi Manuel,

I'm trying stackage-head. I'm following the steps for the scheduled build in .circleci/config.yml. So far steps I took:

- Installed ghc-head (from [1]) to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head (with -fdev) from git repos, using stack. - export BUILD_PLAN=nightly-2018-07-30 (from config.yml) - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml

Now I'm doing

- ./.local/bin/stackage-head already-seen --target $BUILD_PLAN --ghc-metadata metadata.json --outdir build-reports

but it's failing with

The combination of target and commit is new to me

Any ideas what I'm doing wrong?

Thanks

[1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/...

Ömer

Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28 tarihinde şunu yazdı:

...
Thanks for both suggestions. I'll try both and see which one works better.

Ömer

Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15 tarihinde şunu yazdı:

...
Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers, Manuel

...
Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan :

Hi,

I'd like to test some GHC builds + some compile and runtime flag combinations against a large set of packages by building them and running test suites. For this I need

- A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better)

I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details.

Thanks,

Ömer _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Artem Pelenitsyn

5:05 a.m.

Hello Ömer, Just a week ago I asked very similar question: how to install the test suite dependencies after breaking changes in GHC: https://mail.haskell.org/pipermail/ghc-devs/2018-August/016075.html But no one replied :( The task seems to be not solvable even if an affected package (stm in your case and primitive in mine) has already adopted in its master the breaking change but has no corresponding release on Hackage (which will always be the case, because how would you release depending on base which hasn't been released yet). Some package managers in other languages (Julia's Pkg, go install) allow you to depend directly on master branch of a package if you wish to. I wonder if there is a road here for cabal to take in order to support this kind of unsafe installs. -- Best wishes, Artem On Fri, 10 Aug 2018, 11:40 Ömer Sinan Ağacan, wrote:

...

Hi,

This is working great, I just generated my first report. One problem is stm-2.4 doesn't compile with GHC HEAD, we need stm-2.5.0.0. But that's not published on Hackage yet, and latest nightly still uses stm-2.4.5.0. I wonder if there's anything that can be done about this. Apparently stm blocks 82 packages (I don't know if that's counting transitively or just packages that are directly blocked by stm). Any ideas about this?

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 14:45 tarihinde şunu yazdı:

...
Ah, I now realize that that command is supposed to print that output.

I'll

...
continue following the steps and keep you updated if I get stuck again.

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 13:20 tarihinde şunu yazdı:

...
Hi Manuel,

I'm trying stackage-head. I'm following the steps for the scheduled

build in

...
.circleci/config.yml. So far steps I took:

- Installed ghc-head (from [1]) to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head (with -fdev) from git repos, using stack. - export BUILD_PLAN=nightly-2018-07-30 (from config.yml) - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml

Now I'm doing

- ./.local/bin/stackage-head already-seen --target $BUILD_PLAN --ghc-metadata metadata.json --outdir build-reports

but it's failing with

The combination of target and commit is new to me

Any ideas what I'm doing wrong?

Thanks

[1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/...

Ömer

Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28 tarihinde şunu yazdı:

...
Thanks for both suggestions. I'll try both and see which one works

better.

...
Ömer

Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15 tarihinde şunu yazdı:

...
Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we

have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

...
...
https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers, Manuel

...
Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan <

omeragacan@gmail.com>:

...
...
Hi,

I'd like to test some GHC builds + some compile and runtime flag

combinations

...
against a large set of packages by building them and running test suites. For this I need

- A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better)

I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details.

Thanks,

Ömer _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Herbert Valerio Riedel

5:29 a.m.

Hi Artem, On Fri, Aug 10, 2018 at 11:05 AM Artem Pelenitsyn wrote:

...

The task seems to be not solvable even if an affected package (stm in your case and primitive in mine) has already adopted in its master the breaking change but has no corresponding release on Hackage (which will always be the case, because how would you release depending on base which hasn't been released yet).

Some package managers in other languages (Julia's Pkg, go install) allow you to depend directly on master branch of a package if you wish to. I wonder if there is a road here for cabal to take in order to support this kind of unsafe installs.

As a matter of fact we have a couple of options here: - Add the http://cand.hackage.haskell.org/ package index to your config and get access to the stm-2.5.0.0 package release candidate (i.e. http://hackage.haskell.org/package/stm-2.5.0.0/candidate/stm-2.5.0.0.tar.gz) - We could have added `stm-2.5.0.0` to the head.hackage overlay (so far the "overlay" has only modified existing packages from the primary hackage index) - Starting with cabal-2.4, we support adding package tarballs to `cabal.project`; and this should work also for specifiying remote tarball locations such as http://hackage.haskell.org/package/stm-2.5.0.0/candidate/stm-2.5.0.0.tar.gz - Starting with cabal 2.4, we do support remote git repo deps in `cabal.project`, see e.g. https://github.com/hvr/cardano-sl/blob/wip/cabal-project/cabal.project#L41-L... for an extensive real-world example. There's work planned to refine/improve these options and make them more convenient/expressive. Help is appreciated if somebody wants to help us get there sooner. -- hvr

Ömer Sinan Ağacan

7:55 a.m.

I also briefly looked at hackage.head. As far as I understand it doesn't out-of-the-box provide a way to build a large set of packages, right? It'd be useful if I had a package that I want to test against GHC HEAD but currently it doesn't help me, unless I'm missing something. Ömer Ömer Sinan Ağacan , 10 Ağu 2018 Cum, 11:39 tarihinde şunu yazdı:

...

Hi,

This is working great, I just generated my first report. One problem is stm-2.4 doesn't compile with GHC HEAD, we need stm-2.5.0.0. But that's not published on Hackage yet, and latest nightly still uses stm-2.4.5.0. I wonder if there's anything that can be done about this. Apparently stm blocks 82 packages (I don't know if that's counting transitively or just packages that are directly blocked by stm). Any ideas about this?

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 14:45 tarihinde şunu yazdı:

...
Ah, I now realize that that command is supposed to print that output. I'll continue following the steps and keep you updated if I get stuck again.

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 13:20 tarihinde şunu yazdı:

...
Hi Manuel,

I'm trying stackage-head. I'm following the steps for the scheduled build in .circleci/config.yml. So far steps I took:

- Installed ghc-head (from [1]) to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head (with -fdev) from git repos, using stack. - export BUILD_PLAN=nightly-2018-07-30 (from config.yml) - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml

Now I'm doing

- ./.local/bin/stackage-head already-seen --target $BUILD_PLAN --ghc-metadata metadata.json --outdir build-reports

but it's failing with

The combination of target and commit is new to me

Any ideas what I'm doing wrong?

Thanks

[1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/...

Ömer

Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28 tarihinde şunu yazdı:

...
Thanks for both suggestions. I'll try both and see which one works better.

Ömer

Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15 tarihinde şunu yazdı:

...
Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers, Manuel

...
Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan :

Hi,

I'd like to test some GHC builds + some compile and runtime flag combinations against a large set of packages by building them and running test suites. For this I need

- A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better)

I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details.

Thanks,

Ömer _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ben Gamari

8:06 p.m.

On August 10, 2018 7:55:38 AM EDT, "Ömer Sinan Ağacan" wrote:

...

I also briefly looked at hackage.head. As far as I understand it doesn't out-of-the-box provide a way to build a large set of packages, right? It'd be useful if I had a package that I want to test against GHC HEAD but currently it doesn't help me, unless I'm missing something.

Ömer

Ömer Sinan Ağacan , 10 Ağu 2018 Cum, 11:39 tarihinde şunu yazdı:

...
Hi,

This is working great, I just generated my first report. One problem

...
doesn't compile with GHC HEAD, we need stm-2.5.0.0. But that's not

...
Hackage yet, and latest nightly still uses stm-2.4.5.0. I wonder if

...
anything that can be done about this. Apparently stm blocks 82

...
don't know if that's counting transitively or just packages that are

...
blocked by stm). Any ideas about this?

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 14:45 tarihinde şunu yazdı:

...
Ah, I now realize that that command is supposed to print that

output. I'll

...
continue following the steps and keep you updated if I get stuck again.

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 13:20 tarihinde şunu yazdı:

...
Hi Manuel,

I'm trying stackage-head. I'm following the steps for the

scheduled build in

...
.circleci/config.yml. So far steps I took:

- Installed ghc-head (from [1]) to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head (with -fdev) from git repos, using stack. - export BUILD_PLAN=nightly-2018-07-30 (from config.yml) - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml

Now I'm doing

- ./.local/bin/stackage-head already-seen --target $BUILD_PLAN --ghc-metadata metadata.json --outdir build-reports

but it's failing with

The combination of target and commit is new to me

Any ideas what I'm doing wrong?

Thanks

[1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/...

Ömer

Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28 tarihinde şunu yazdı:

...
Thanks for both suggestions. I'll try both and see which one

works better.

...
Ömer

Manuel M T Chakravarty , 7 Ağu 2018 Sal,

18:15

...
tarihinde şunu yazdı:

...
Hi Ömer,

This is exactly the motivation for the Stackage HEAD works

is stm-2.4 published on there's packages (I directly that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

...
...
...
...
...
https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

...
Cheers, Manuel

> Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan

:

...
> > Hi, > > I'd like to test some GHC builds + some compile and runtime flag combinations > against a large set of packages by building them and running test suites. For > this I need > > - A set of packages that are known to work with latest GHC > - A way to build them and run their test suites (if I could specify compile and > runtime flags that'd be even better) > > I think stackage can serve as (1) but I don't know how to do (2). Can anyone > point me to the right direction? I vaguely remember some nix-based solution for > this that was being discussed on the IRC channel, but can't recall any details. > > Thanks, > > Ömer > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Head.hackage doesn't have an out of the box package set but it is quite straightforward to construct such a set. While I now tend to use nix, in the past I generally just constructed a dummy cabal package listing the packages of interest as dependencies. There are two approaches to choosing a set of packages: extract the packages from Stackage's build-constraints.yaml or just additively build up a set from the top of your head. I find the latter is often more realistic; stackage is now large enough that even getting a fraction of it to build with a prerelease compiler can be a significant undertaking.

Joachim Breitner

11 Aug 11 Aug

1:48 p.m.

Hi, Am Freitag, den 10.08.2018, 20:06 -0400 schrieb Ben Gamari:

...

Head.hackage doesn't have an out of the box package set but it is quite straightforward to construct such a set. While I now tend to use nix, in the past I generally just constructed a dummy cabal package listing the packages of interest as dependencies.

There are two approaches to choosing a set of packages: extract the packages from Stackage's build-constraints.yaml or just additively build up a set from the top of your head. I find the latter is often more realistic; stackage is now large enough that even getting a fraction of it to build with a prerelease compiler can be a significant undertaking.

here is another package set worth considering, if you want a representative collection of packages with (somewhat) significance: The packages distributed by Debian: https://salsa.debian.org/haskell-team/package-plan/raw/master/packages.txt Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Gert-Jan Bottu

25 Jul 25 Jul

5:23 a.m.

Hi, I'm trying to do something similar : I'm hacking around with GHC, and would like to build a large set of packages to verify my changes. Similarly to the steps described below, I've followed the scheduled build in .circle/config.yml, but I can't figure out how to force it to use my own (hacked upon) GHC build? More concretely, the steps I took (from the lastest .circle/config.yml): - Installed my local GHC to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head from git repos - export BUILD_PLAN=nightly-2018-10-23 - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml - fix-build-plan $BUILD_PLAN.yaml custom-source-urls.yaml - stackage-curator make-bundle --allow-newer --jobs 9 --plan-file $BUILD_PLAN.yaml --docmap-file docmap-file.yaml --target $BUILD_PLAN --skip-haddock --skip-hoogle --skip-benches --no-rebuild-cabal -v > build.log 2>&1 This manages to build Stackage and generate a report just fine, but it doesn't use my ~/ghc-head GHC install. Any ideas how I can point stackage-curator to a specific GHC install? Thanks Gert-Jan On 10.08.18 10:39, Ömer Sinan Ağacan wrote:

...

Hi,

This is working great, I just generated my first report. One problem is stm-2.4 doesn't compile with GHC HEAD, we need stm-2.5.0.0. But that's not published on Hackage yet, and latest nightly still uses stm-2.4.5.0. I wonder if there's anything that can be done about this. Apparently stm blocks 82 packages (I don't know if that's counting transitively or just packages that are directly blocked by stm). Any ideas about this?

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 14:45 tarihinde şunu yazdı:

...
Ah, I now realize that that command is supposed to print that output. I'll continue following the steps and keep you updated if I get stuck again.

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 13:20 tarihinde şunu yazdı:

...
Hi Manuel,

I'm trying stackage-head. I'm following the steps for the scheduled build in .circleci/config.yml. So far steps I took:

- Installed ghc-head (from [1]) to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head (with -fdev) from git repos, using stack. - export BUILD_PLAN=nightly-2018-07-30 (from config.yml) - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml

Now I'm doing

- ./.local/bin/stackage-head already-seen --target $BUILD_PLAN --ghc-metadata metadata.json --outdir build-reports

but it's failing with

The combination of target and commit is new to me

Any ideas what I'm doing wrong?

Thanks

[1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/...

Ömer

Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28 tarihinde şunu yazdı:

...
Thanks for both suggestions. I'll try both and see which one works better.

Ömer

Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15 tarihinde şunu yazdı:

...
Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers, Manuel

...
Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan :

Hi,

I'd like to test some GHC builds + some compile and runtime flag combinations against a large set of packages by building them and running test suites. For this I need

- A set of packages that are known to work with latest GHC - A way to build them and run their test suites (if I could specify compile and runtime flags that'd be even better)

I think stackage can serve as (1) but I don't know how to do (2). Can anyone point me to the right direction? I vaguely remember some nix-based solution for this that was being discussed on the IRC channel, but can't recall any details.

Thanks,

Ömer _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Matthew Pickering

10:17 a.m.

Hi Gert-Jan, Have you considered using the head.hackage infrastructure? There is a CI job which builds a set of package with HEAD. It is designed for this kind of testing. In order to test it on your branch you probably just need to it at a suitable bindist. Cheers, Matt On Thu, Jul 25, 2019 at 3:10 PM Gert-Jan Bottu wrote:

...

Hi,

I'm trying to do something similar : I'm hacking around with GHC, and would like to build a large set of packages to verify my changes. Similarly to the steps described below, I've followed the scheduled build in .circle/config.yml, but I can't figure out how to force it to use my own (hacked upon) GHC build?

More concretely, the steps I took (from the lastest .circle/config.yml): - Installed my local GHC to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head from git repos - export BUILD_PLAN=nightly-2018-10-23 - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml - fix-build-plan $BUILD_PLAN.yaml custom-source-urls.yaml - stackage-curator make-bundle --allow-newer --jobs 9 --plan-file $BUILD_PLAN.yaml --docmap-file docmap-file.yaml --target $BUILD_PLAN --skip-haddock --skip-hoogle --skip-benches --no-rebuild-cabal -v > build.log 2>&1

This manages to build Stackage and generate a report just fine, but it doesn't use my ~/ghc-head GHC install. Any ideas how I can point stackage-curator to a specific GHC install?

Thanks

Gert-Jan

On 10.08.18 10:39, Ömer Sinan Ağacan wrote:

...
Hi,

This is working great, I just generated my first report. One problem is stm-2.4 doesn't compile with GHC HEAD, we need stm-2.5.0.0. But that's not published on Hackage yet, and latest nightly still uses stm-2.4.5.0. I wonder if there's anything that can be done about this. Apparently stm blocks 82 packages (I don't know if that's counting transitively or just packages that are directly blocked by stm). Any ideas about this?

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 14:45 tarihinde şunu yazdı:

...
Ah, I now realize that that command is supposed to print that output. I'll continue following the steps and keep you updated if I get stuck again.

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 13:20 tarihinde şunu yazdı:

...
Hi Manuel,

I'm trying stackage-head. I'm following the steps for the scheduled build in .circleci/config.yml. So far steps I took:

- Installed ghc-head (from [1]) to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head (with -fdev) from git repos, using stack. - export BUILD_PLAN=nightly-2018-07-30 (from config.yml) - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml

Now I'm doing

- ./.local/bin/stackage-head already-seen --target $BUILD_PLAN --ghc-metadata metadata.json --outdir build-reports

but it's failing with

The combination of target and commit is new to me

Any ideas what I'm doing wrong?

Thanks

[1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/...

Ömer

Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28 tarihinde şunu yazdı:

...
Thanks for both suggestions. I'll try both and see which one works better.

Ömer

Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15 tarihinde şunu yazdı:

...
Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers, Manuel

> Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan : > > Hi, > > I'd like to test some GHC builds + some compile and runtime flag combinations > against a large set of packages by building them and running test suites. For > this I need > > - A set of packages that are known to work with latest GHC > - A way to build them and run their test suites (if I could specify compile and > runtime flags that'd be even better) > > I think stackage can serve as (1) but I don't know how to do (2). Can anyone > point me to the right direction? I vaguely remember some nix-based solution for > this that was being discussed on the IRC channel, but can't recall any details. > > Thanks, > > Ömer > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ben Gamari

12:01 p.m.

Gert-Jan Bottu writes:

...

Hi,

I'm trying to do something similar : I'm hacking around with GHC, and would like to build a large set of packages to verify my changes. Similarly to the steps described below, I've followed the scheduled build in .circle/config.yml, but I can't figure out how to force it to use my own (hacked upon) GHC build?

I can't comment on stackage-curator but would second mpickering's question. head.hackage is designed precisely for this sort of application. I have a pair of draft blog posts [1,2], to be published soon, which document its usage. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/homepage/merge_requests/16 [2] https://gitlab.haskell.org/ghc/homepage/merge_requests/29

Sylvain Henry

12:28 p.m.

Hi, I've never used stackage-curator but "curator 2.0" [1] seems to generate a stack.yaml file that can be used by Stack to build all the packages of the selected snapshot. As Stack supports installing GHC bindists and Stack 2.0 even supports building and installing GHC from a GIT repository [2], you should just have to edit the generated stack.yaml file to use another compiler. Cheers, Sylvain [1] https://github.com/commercialhaskell/curator [2] https://docs.haskellstack.org/en/stable/yaml_configuration/#building-ghc-fro... On 25/07/2019 11:23, Gert-Jan Bottu wrote:

...

Hi,

I'm trying to do something similar : I'm hacking around with GHC, and would like to build a large set of packages to verify my changes. Similarly to the steps described below, I've followed the scheduled build in .circle/config.yml, but I can't figure out how to force it to use my own (hacked upon) GHC build?

More concretely, the steps I took (from the lastest .circle/config.yml): - Installed my local GHC to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head from git repos - export BUILD_PLAN=nightly-2018-10-23 - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml - fix-build-plan $BUILD_PLAN.yaml custom-source-urls.yaml - stackage-curator make-bundle --allow-newer --jobs 9 --plan-file $BUILD_PLAN.yaml --docmap-file docmap-file.yaml --target $BUILD_PLAN --skip-haddock --skip-hoogle --skip-benches --no-rebuild-cabal -v > build.log 2>&1

This manages to build Stackage and generate a report just fine, but it doesn't use my ~/ghc-head GHC install. Any ideas how I can point stackage-curator to a specific GHC install?

Thanks

Gert-Jan

On 10.08.18 10:39, Ömer Sinan Ağacan wrote:

...
Hi,

This is working great, I just generated my first report. One problem is stm-2.4 doesn't compile with GHC HEAD, we need stm-2.5.0.0. But that's not published on Hackage yet, and latest nightly still uses stm-2.4.5.0. I wonder if there's anything that can be done about this. Apparently stm blocks 82 packages (I don't know if that's counting transitively or just packages that are directly blocked by stm). Any ideas about this?

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 14:45 tarihinde şunu yazdı:

...
Ah, I now realize that that command is supposed to print that output. I'll continue following the steps and keep you updated if I get stuck again.

Ömer

Ömer Sinan Ağacan , 9 Ağu 2018 Per, 13:20 tarihinde şunu yazdı:

...
Hi Manuel,

I'm trying stackage-head. I'm following the steps for the scheduled build in .circleci/config.yml. So far steps I took:

- Installed ghc-head (from [1]) to ~/ghc-head - Installed stackage-build-plan, stackage-curator and stackage-head (with    -fdev) from git repos, using stack. - export BUILD_PLAN=nightly-2018-07-30 (from config.yml) - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/... --output metadata.json - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.y... --output $BUILD_PLAN.yaml

Now I'm doing

- ./.local/bin/stackage-head already-seen --target $BUILD_PLAN --ghc-metadata metadata.json --outdir build-reports

but it's failing with

     The combination of target and commit is new to me

Any ideas what I'm doing wrong?

Thanks

[1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/...

Ömer

Ömer Sinan Ağacan , 7 Ağu 2018 Sal, 23:28 tarihinde şunu yazdı:

...
Thanks for both suggestions. I'll try both and see which one works better.

Ömer

Manuel M T Chakravarty , 7 Ağu 2018 Sal, 18:15 tarihinde şunu yazdı:

...
Hi Ömer,

This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at

   https://github.com/tweag/stackage-head

and also the blog post from when the first version went live:

https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html

Cheers, Manuel

> Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan > : > > Hi, > > I'd like to test some GHC builds + some compile and runtime flag > combinations > against a large set of packages by building them and running > test suites. For > this I need > > - A set of packages that are known to work with latest GHC > - A way to build them and run their test suites (if I could > specify compile and > runtime flags that'd be even better) > > I think stackage can serve as (1) but I don't know how to do > (2). Can anyone > point me to the right direction? I vaguely remember some > nix-based solution for > this that was being discussed on the IRC channel, but can't > recall any details. > > Thanks, > > Ömer > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2126

Age (days ago)

2479

Last active (days ago)

List overview

Download

15 comments

9 participants

participants (9)

Artem Pelenitsyn
Ben Gamari
Gert-Jan Bottu
Herbert Valerio Riedel
Joachim Breitner
Manuel M T Chakravarty
Matthew Pickering
Sylvain Henry
Ömer Sinan Ağacan

Any ways to test a GHC build against large set of packages (including test suites)?

tags

participants (9)