Getting containers updated in Stackage

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Getting containers updated in Stackage

David Feuer
It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it?

Thanks,
David

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Haskell-cafe] Getting containers updated in Stackage

Sven Panne-2
2017-04-01 20:53 GMT+02:00 David Feuer <[hidden email]>:
It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it?

If I see this correctly, there is nothing to take care of: Stackage nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. When a new GHC is released and that ships with a new version of containers, it will be on Stackage. Apart from that, there is nothing you can do: Stackage is there to have a consistent set of packages, so containers is not even in https://github.com/fpco/stackage/blob/master/build-constraints.yaml, because it ships with GHC.

That's at least my understanding...

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Haskell-cafe] Getting containers updated in Stackage

David Feuer
The fact that GHC needs to have its own containers shouldn't prevent a consistent package set from using a different one. The only hypothetical problem would be if the GHC API leaked containers types, but I'm pretty sure it doesn't: they're all wrapped up in newtypes and exported abstractly, unless someone's made a mistake.

On Apr 1, 2017 6:09 PM, "Sven Panne" <[hidden email]> wrote:
2017-04-01 20:53 GMT+02:00 David Feuer <[hidden email]>:
It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it?

If I see this correctly, there is nothing to take care of: Stackage nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. When a new GHC is released and that ships with a new version of containers, it will be on Stackage. Apart from that, there is nothing you can do: Stackage is there to have a consistent set of packages, so containers is not even in https://github.com/fpco/stackage/blob/master/build-constraints.yaml, because it ships with GHC.

That's at least my understanding...

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Haskell-cafe] Getting containers updated in Stackage

Adam Bergmark-2
Hi David,

As far as I know stackage doesn't have a mechanism to say "this might cause version mismatches but I promise it won't", is there even a way to do that with Cabal (which stackage uses)?

Cheers,
Adam


On Sun, 2 Apr 2017 at 01:26 David Feuer <[hidden email]> wrote:
The fact that GHC needs to have its own containers shouldn't prevent a consistent package set from using a different one. The only hypothetical problem would be if the GHC API leaked containers types, but I'm pretty sure it doesn't: they're all wrapped up in newtypes and exported abstractly, unless someone's made a mistake.

On Apr 1, 2017 6:09 PM, "Sven Panne" <[hidden email]> wrote:
2017-04-01 20:53 GMT+02:00 David Feuer <[hidden email]>:
It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it?

If I see this correctly, there is nothing to take care of: Stackage nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. When a new GHC is released and that ships with a new version of containers, it will be on Stackage. Apart from that, there is nothing you can do: Stackage is there to have a consistent set of packages, so containers is not even in https://github.com/fpco/stackage/blob/master/build-constraints.yaml, because it ships with GHC.

That's at least my understanding...
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Haskell-cafe] Getting containers updated in Stackage

David Feuer
What I'm suggesting is a bit narrower: I think stack should probably just ignore GHC boot packages altogether, aside from the necessary ones (I think just ghc-prim, ghc, base, and array, but you'd have to check the full GHC API to be sure). Never use them, and pretend they don't exist.

On Apr 2, 2017 6:47 AM, "Adam Bergmark" <[hidden email]> wrote:
Hi David,

As far as I know stackage doesn't have a mechanism to say "this might cause version mismatches but I promise it won't", is there even a way to do that with Cabal (which stackage uses)?

Cheers,
Adam


On Sun, 2 Apr 2017 at 01:26 David Feuer <[hidden email]> wrote:
The fact that GHC needs to have its own containers shouldn't prevent a consistent package set from using a different one. The only hypothetical problem would be if the GHC API leaked containers types, but I'm pretty sure it doesn't: they're all wrapped up in newtypes and exported abstractly, unless someone's made a mistake.

On Apr 1, 2017 6:09 PM, "Sven Panne" <[hidden email]> wrote:
2017-04-01 20:53 GMT+02:00 David Feuer <[hidden email]>:
It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it?

If I see this correctly, there is nothing to take care of: Stackage nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. When a new GHC is released and that ships with a new version of containers, it will be on Stackage. Apart from that, there is nothing you can do: Stackage is there to have a consistent set of packages, so containers is not even in https://github.com/fpco/stackage/blob/master/build-constraints.yaml, because it ships with GHC.

That's at least my understanding...
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Haskell-cafe] Getting containers updated in Stackage

Sven Panne-2
2017-04-02 18:24 GMT+02:00 David Feuer <[hidden email]>:
What I'm suggesting is a bit narrower: I think stack should probably just ignore GHC boot packages altogether, aside from the necessary ones (I think just ghc-prim, ghc, base, and array, but you'd have to check the full GHC API to be sure). Never use them, and pretend they don't exist.

My personal understanding of Stackage is: It's a collection of packages with *exactly* one version of each package, and all those versions are guaranteed to work together. (<= Well, at least in the eyes of the resolver, not necessarily in a semantic way) So: As long as GHC exposes its "non-necessary" packages, whatever that means in detail, I doubt that there will be other versions of them on Stackage. That's what Hackage is for...

Again: That's at least my understanding...

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Haskell-cafe] Getting containers updated in Stackage

Edward Kmett-2
In reply to this post by David Feuer
That doesn't work if you link against ghc the library.  If I run

ghc-pkg describe ghc 

on my slightly old install, it shows

depends:
    array-0.5.1.1 base-4.9.0.0 binary-0.8.3.0 bytestring-0.10.8.1
    containers-0.5.7.1 directory-1.2.6.2 filepath-1.4.1.0
    ghc-boot-8.0.1 ghci-8.0.1 hoopl-3.10.2.1 hpc-0.6.0.3
    process-1.4.2.0 template-haskell-2.11.0.0 time-1.6.0.1
    transformers-0.5.2.0 unix-2.7.2.0

If any of these are upgraded independently of ghc then every package that depends on both ghc will start to fail to build due to needing to link two versions of the same dependency. Examples of packages that depend on ghc with wide distribution that lots of folks depend on in at least one configuration of their builds? doctest 

This makes this a fairly crippling distribution hazard for something like stackage that runs the unit tests that comes with the packages it provides. =)

Back in the day ghc used to maintain its own forks of many of its dependencies to avoid some of these sorts of issues. It doesn't do so any more.

-Edward

On Sun, Apr 2, 2017 at 12:24 PM, David Feuer <[hidden email]> wrote:
What I'm suggesting is a bit narrower: I think stack should probably just ignore GHC boot packages altogether, aside from the necessary ones (I think just ghc-prim, ghc, base, and array, but you'd have to check the full GHC API to be sure). Never use them, and pretend they don't exist.

On Apr 2, 2017 6:47 AM, "Adam Bergmark" <[hidden email]> wrote:
Hi David,

As far as I know stackage doesn't have a mechanism to say "this might cause version mismatches but I promise it won't", is there even a way to do that with Cabal (which stackage uses)?

Cheers,
Adam


On Sun, 2 Apr 2017 at 01:26 David Feuer <[hidden email]> wrote:
The fact that GHC needs to have its own containers shouldn't prevent a consistent package set from using a different one. The only hypothetical problem would be if the GHC API leaked containers types, but I'm pretty sure it doesn't: they're all wrapped up in newtypes and exported abstractly, unless someone's made a mistake.

On Apr 1, 2017 6:09 PM, "Sven Panne" <[hidden email]> wrote:
2017-04-01 20:53 GMT+02:00 David Feuer <[hidden email]>:
It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it?

If I see this correctly, there is nothing to take care of: Stackage nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. When a new GHC is released and that ships with a new version of containers, it will be on Stackage. Apart from that, there is nothing you can do: Stackage is there to have a consistent set of packages, so containers is not even in https://github.com/fpco/stackage/blob/master/build-constraints.yaml, because it ships with GHC.

That's at least my understanding...
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Haskell-cafe] Getting containers updated in Stackage

Herbert Valerio Riedel-3
In reply to this post by David Feuer
Hi,

On 2017-04-02 at 01:23:52 +0200, David Feuer wrote:
> The fact that GHC needs to have its own containers shouldn't prevent a
> consistent package set from using a different one. The only hypothetical
> problem would be if the GHC API leaked containers types, but I'm pretty
> sure it doesn't: they're all wrapped up in newtypes and exported
> abstractly, unless someone's made a mistake.

Fwiw, I just opened up the GHC api haddocks and arbitrarily picked a
module and sure enough I was able to find a use of an exposed container
type rightaway, specificially `IntMap`:

https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.0.1/HscTypes.html#t:ModBreaks

I'd expect to easily find more leaked types from containers and other
dependencies.


Relatedly, I don't think it's a good idea to implement support for
internal/private dependencies at this point yet w/o first having the
tools to verify that types that are supposed to stay hidden don't leak
through the exposed API. Otoh, tools for doing this kind of static
analysis are also needed to verify the existing API versioning contract
we already use now. And once we have such go-to tooling, it should be
easy to build on top of that.

However, if we wanted to decouple `ghc` from `containers` (and possibly
other packages, such as process/transformers/unix/bytestring/binary) by
declaring the use of its `container` types private/internal to `ghc`'s
API, we could just go back to do what we did years ago (e.g. in GHC
7.0.4) by using renamed packages like `ghc-binary` (but also revisit the
reasons why we don't do this anymore...).

Another approach would be to make the `ghc` package recompilable by
`cabal`. I briefly tried that[1] but got side-tracked, and I still believe it should be possible to get the
`ghc` package to the point where it's an ordinary `cabal`-buildable
package.




 [1]: Not the least, so I could upload it to Hackage and have its
      Haddocks being generated without too much magic; but more
      importantly so that cabal would be less constrained when solving
      for install-plans when `ghc` is involved, as well as GHC HQ being
      able to more easily pick up new dependencies for `ghc` w/o having
      to introduce yet another congestion point in terms of dependency
      constraints (i.e. packages depended upon by `ghc` are effectively
      frozen to those picked by a given GHC release once `ghc` enters an
      install-plan).
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Loading...