Testing that packages still compile

Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Testing that packages still compile

Sébastien Hinderer
Dear all,

I am part of the OCaml development team. As you may know, OCaml has a
package manager a bit similar to cabal whose name is opam.

One of my colleagues spends quite a lot of time trying to make sure that
packages still compile with a new version of the compiler, when we
release it. When a package does not compile any longer, it seems it is a
highly non-trivial task to figure out what exactly is broken: is it the
package itself which has been broken by a change in the compiler, or is
it one of its dependencies.

I am assuming the same kind of problems occur with Haskell and am
wondering how they are handle.

Has there been something published on this kind of problem?

Any pointer, comment or contact appreciated.

Best wishes,

Sébastien.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Testing that packages still compile

davean
My experience may not be representative, but I've done waves of updating packages for a new major GHC release a few times now. I believe for the AMP-containing update of GHC I submitted patches to over 40 packages. My experience is far from universal, but I extensive enough to be informative.

In my experience, Haskell's types gave precise sources for the error. As the packages form a DAG, issues with dependency packages were sorted out before I got to packages using them since the types caught any issues at the point that package was compiled. By when the dependent package was compiled, the type signatures of the dependency package was decided, and any compilation issues represented a legitimate API change requiring a patch to the package failing to compile. GHC flagged these issues at the point of use. Only rarely did I have to look in more than one place, and in those cases, it was universally inside the same package. Most of these were caused by changes in the unifier and were from the use of moderately exotic type system extensions that were purposefully changed causing disagreement inside the package about how to resolve the types since the design depended on ambiguity.

Other than this last case, fixing the packages has been almost entirely procedural. It might take some time and familiarization with the package to make sure the change made was of sufficient quality to warrant submitting a patch instead of merely being correct, but it was never any mystery where the problem lay. I'd be curious what sort of issues you're encountering that caused confusion about the origin point of the issue. Its been over a decade since I used an ML language though so I'm not sure how Ocaml's type level specifications interact across packages. OCaml has some features that seem like they may lead to less orderly resolution of such problems (module functors come to mind as potentially interfering with the orderly nature of package dependencies).

-davean

On Thu, May 31, 2018 at 5:32 AM, Sébastien Hinderer <[hidden email]> wrote:
Dear all,

I am part of the OCaml development team. As you may know, OCaml has a
package manager a bit similar to cabal whose name is opam.

One of my colleagues spends quite a lot of time trying to make sure that
packages still compile with a new version of the compiler, when we
release it. When a package does not compile any longer, it seems it is a
highly non-trivial task to figure out what exactly is broken: is it the
package itself which has been broken by a change in the compiler, or is
it one of its dependencies.

I am assuming the same kind of problems occur with Haskell and am
wondering how they are handle.

Has there been something published on this kind of problem?

Any pointer, comment or contact appreciated.

Best wishes,

Sébastien.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Testing that packages still compile

Carter Schonwald
It may be that there’s quite a bit of code that doesn’t have explicit top level type signatures?  That’s legal in Haskell but considered bad style / bad practice for packages.  I’m not sure if the norms in O’Caml reflect the same inclination. This may complicate localizing type errors 

On Thu, May 31, 2018 at 11:51 AM davean <[hidden email]> wrote:
My experience may not be representative, but I've done waves of updating packages for a new major GHC release a few times now. I believe for the AMP-containing update of GHC I submitted patches to over 40 packages. My experience is far from universal, but I extensive enough to be informative.

In my experience, Haskell's types gave precise sources for the error. As the packages form a DAG, issues with dependency packages were sorted out before I got to packages using them since the types caught any issues at the point that package was compiled. By when the dependent package was compiled, the type signatures of the dependency package was decided, and any compilation issues represented a legitimate API change requiring a patch to the package failing to compile. GHC flagged these issues at the point of use. Only rarely did I have to look in more than one place, and in those cases, it was universally inside the same package. Most of these were caused by changes in the unifier and were from the use of moderately exotic type system extensions that were purposefully changed causing disagreement inside the package about how to resolve the types since the design depended on ambiguity.

Other than this last case, fixing the packages has been almost entirely procedural. It might take some time and familiarization with the package to make sure the change made was of sufficient quality to warrant submitting a patch instead of merely being correct, but it was never any mystery where the problem lay. I'd be curious what sort of issues you're encountering that caused confusion about the origin point of the issue. Its been over a decade since I used an ML language though so I'm not sure how Ocaml's type level specifications interact across packages. OCaml has some features that seem like they may lead to less orderly resolution of such problems (module functors come to mind as potentially interfering with the orderly nature of package dependencies).

-davean

On Thu, May 31, 2018 at 5:32 AM, Sébastien Hinderer <[hidden email]> wrote:
Dear all,

I am part of the OCaml development team. As you may know, OCaml has a
package manager a bit similar to cabal whose name is opam.

One of my colleagues spends quite a lot of time trying to make sure that
packages still compile with a new version of the compiler, when we
release it. When a package does not compile any longer, it seems it is a
highly non-trivial task to figure out what exactly is broken: is it the
package itself which has been broken by a change in the compiler, or is
it one of its dependencies.

I am assuming the same kind of problems occur with Haskell and am
wondering how they are handle.

Has there been something published on this kind of problem?

Any pointer, comment or contact appreciated.

Best wishes,

Sébastien.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Testing that packages still compile

Mikolaj Konarski-2
In reply to this post by Sébastien Hinderer
You may also be interested in the "Hackage Matrix CI" links
on Hackage pages and the non-maintainer updates
of packages performed as part of the service to the community.

On Thu, May 31, 2018 at 11:32 AM, Sébastien Hinderer
<[hidden email]> wrote:

> Dear all,
>
> I am part of the OCaml development team. As you may know, OCaml has a
> package manager a bit similar to cabal whose name is opam.
>
> One of my colleagues spends quite a lot of time trying to make sure that
> packages still compile with a new version of the compiler, when we
> release it. When a package does not compile any longer, it seems it is a
> highly non-trivial task to figure out what exactly is broken: is it the
> package itself which has been broken by a change in the compiler, or is
> it one of its dependencies.
>
> I am assuming the same kind of problems occur with Haskell and am
> wondering how they are handle.
>
> Has there been something published on this kind of problem?
>
> Any pointer, comment or contact appreciated.
>
> Best wishes,
>
> Sébastien.
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users