JP Moresmau | 6 Sep 13:51 2013
Picon

GHC API + Cabal API + Cabal version checks: is there a way out?

Hello all,

I have an issue that has been nagging me for a while, and I'd like to make sure I haven't missed a solution to it.
I'm the maintainer for the buildwrapper package. This package has dependencies on the Cabal and GHC libraries, and also uses the cabal-install executable. For example it will run cabal configure by invoking the executable, then it will load the LocalBuildInfo via the Cabal API, and extract the relevant information to start a GHC session with the proper flags, etc.
Now yesterday some great news were announced, a new version of Cabal!
However, I can't use it. I can of course install the Cabal library and rebuild the cabal executable but
- buildwrapper will only use the version of the Cabal library that was bundled with GHC, since the GHC library has a dependency on that version of Cabal
- so the library access will be using Cabal 1.16, but the executable will be 1.18
- and the library checks when reading the setup-config file that the Cabal versions match. Hence, running configure with 1.18 create build information I can't read back in 1.16.

So I'm stuck. People can easily install cabal 1.18 and build their projects with it, but I can't use it in conjunction with buildwrapper.
Some solutions I've considered
- do not use the Cabal API and write my own code to read the local build info, and to replace all the Cabal library code I use
- do not use the cabal-install executable but do everything by the API

Both solutions reek of madness, and involve rewriting code that others have already written, and a maintenance nightmare with each Cabal release.

So, do I have to wait a new release of GHC/Haskell Platform or is there a better solution? I suspect ghc-mod and other similar packages have the same issues.

Thanks for any help!

--
JP Moresmau
http://jpmoresmau.blogspot.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Yuri de Wit | 6 Sep 15:13 2013
Picon

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

I spent some time looking into the touch points between ghc and cabal in the past, and the first oddity i saw was a direct dependency from ghc to the cabal sources. After taking a closer look it seems that ghc shares some common, low level modules with cabal that didnt seem to justify the whole dependency. 


The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue.

Re: specific workaround i am not sure.

On Friday, September 6, 2013, JP Moresmau wrote:
Hello all,

I have an issue that has been nagging me for a while, and I'd like to make sure I haven't missed a solution to it.
I'm the maintainer for the buildwrapper package. This package has dependencies on the Cabal and GHC libraries, and also uses the cabal-install executable. For example it will run cabal configure by invoking the executable, then it will load the LocalBuildInfo via the Cabal API, and extract the relevant information to start a GHC session with the proper flags, etc.
Now yesterday some great news were announced, a new version of Cabal!
However, I can't use it. I can of course install the Cabal library and rebuild the cabal executable but
- buildwrapper will only use the version of the Cabal library that was bundled with GHC, since the GHC library has a dependency on that version of Cabal
- so the library access will be using Cabal 1.16, but the executable will be 1.18
- and the library checks when reading the setup-config file that the Cabal versions match. Hence, running configure with 1.18 create build information I can't read back in 1.16.

So I'm stuck. People can easily install cabal 1.18 and build their projects with it, but I can't use it in conjunction with buildwrapper.
Some solutions I've considered
- do not use the Cabal API and write my own code to read the local build info, and to replace all the Cabal library code I use
- do not use the cabal-install executable but do everything by the API

Both solutions reek of madness, and involve rewriting code that others have already written, and a maintenance nightmare with each Cabal release.

So, do I have to wait a new release of GHC/Haskell Platform or is there a better solution? I suspect ghc-mod and other similar packages have the same issues.

Thanks for any help!

--
JP Moresmau
http://jpmoresmau.blogspot.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Niklas Hambüchen | 6 Sep 15:42 2013

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote:
> The right solution, imho, is to review these dependencies and move
> the low level ones out into a separate package that is shared by both
> ghc and cabal and that will rarely change. The direct side effect of
> this is that ghc would not be tied directly to a specific cabal
> version and you would not have to deal with this issue.

This sounds very right to me.

There should be something that describes what a GHC package database 
is, as minimally as possible (perhaps even only the data types).

In the end, ghc is the defining side here - cabal is only a tool that 
builds on top of these definitions.

Then ghc could finally be decoupled from Cabal.
Roman Cheplyaka | 6 Sep 15:52 2013

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

The right solution for Cabal would be not to know anything about the
GHC's database format at all.

GHC and cabal communicate via a command line interface (`ghc-pkg dump`
in our direction; `ghc-pkg update` in the other). So it would suffice to
have a library which implements parsing and printing of the package
description, and have that library shared between GHC and Cabal.

(Which I think is more or less what you guys are suggesting, only I'd
like to point out that we should be focusing on the protocol instead of
the database format. The latter should be opaque.)

Roman

* Niklas Hambüchen <mail <at> nh2.me> [2013-09-06 22:42:28+0900]
> On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote:
> > The right solution, imho, is to review these dependencies and move
> > the low level ones out into a separate package that is shared by both
> > ghc and cabal and that will rarely change. The direct side effect of
> > this is that ghc would not be tied directly to a specific cabal
> > version and you would not have to deal with this issue.
> 
> This sounds very right to me.
> 
> There should be something that describes what a GHC package database 
> is, as minimally as possible (perhaps even only the data types).
> 
> In the end, ghc is the defining side here - cabal is only a tool that 
> builds on top of these definitions.
> 
> Then ghc could finally be decoupled from Cabal.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Niklas Hambüchen | 6 Sep 16:17 2013

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

On Fri 06 Sep 2013 22:52:40 JST, Roman Cheplyaka wrote:
> The right solution for Cabal would be not to know anything about the
> GHC's database format at all.
>
> GHC and cabal communicate via a command line interface (`ghc-pkg dump`
> in our direction; `ghc-pkg update` in the other). So it would suffice to
> have a library which implements parsing and printing of the package
> description, and have that library shared between GHC and Cabal.

You are right. This is better.

GHC's dependency on cabal seems to actually be quite minimal!

I did a quick grep:

% grep -rI "import Distribution" --include "*.hs" --include "*.lhs*" . 
| grep -v "libraries/" | grep -v Setup.hs | grep -v Setup.lhs | grep -v 
utils/haddock
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Check 
hiding (doesFileExist)
./utils/ghc-cabal/Main.hs:import 
Distribution.PackageDescription.Configuration
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Parse
./utils/ghc-cabal/Main.hs:import Distribution.System
./utils/ghc-cabal/Main.hs:import Distribution.Simple
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Configure
./utils/ghc-cabal/Main.hs:import Distribution.Simple.LocalBuildInfo
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program.HcPkg
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Utils 
(defaultPackageDesc, writeFileAtomic, toUTF8)
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Build 
(writeAutogenFiles)
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Register
./utils/ghc-cabal/Main.hs:import Distribution.Text
./utils/ghc-cabal/Main.hs:import Distribution.Verbosity
./utils/ghctags/Main.hs:import Distribution.Simple.GHC ( 
componentGhcOptions )
./utils/ghctags/Main.hs:import Distribution.Simple.Configure ( 
getPersistBuildConfig )
./utils/ghctags/Main.hs:import Distribution.Simple.Compiler ( 
compilerVersion )
./utils/ghctags/Main.hs:import Distribution.Simple.Program.GHC ( 
renderGhcOptions )
./utils/ghctags/Main.hs:import Distribution.PackageDescription ( 
library, libBuildInfo )
./utils/ghctags/Main.hs:import Distribution.Simple.LocalBuildInfo
./utils/ghc-pkg/Main.hs:import 
Distribution.InstalledPackageInfo.Binary()
./utils/ghc-pkg/Main.hs:import Distribution.ModuleName hiding (main)
./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo
./utils/ghc-pkg/Main.hs:import Distribution.Compat.ReadP
./utils/ghc-pkg/Main.hs:import Distribution.ParseUtils
./utils/ghc-pkg/Main.hs:import Distribution.Package hiding (depends)
./utils/ghc-pkg/Main.hs:import Distribution.Text
./utils/ghc-pkg/Main.hs:import Distribution.Version
./compiler/ghci/Linker.lhs:import Distribution.Package hiding (depends, 
PackageId)
./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo
./compiler/main/Packages.lhs:import 
Distribution.InstalledPackageInfo.Binary
./compiler/main/Packages.lhs:import Distribution.Package hiding 
(PackageId,depends)
./compiler/main/PackageConfig.hs:import 
Distribution.InstalledPackageInfo
./compiler/main/PackageConfig.hs:import Distribution.ModuleName
./compiler/main/PackageConfig.hs:import Distribution.Package hiding 
(PackageId)
./compiler/main/PackageConfig.hs:import Distribution.Text
./compiler/main/PackageConfig.hs:import Distribution.Version
./compiler/main/Finder.lhs:import Distribution.Text
./compiler/main/Finder.lhs:import Distribution.Package hiding 
(PackageId)

As you can see, there are only 4 files in ghc itself that depend on 
Cabal:

./compiler/ghci/Linker.lhs
./compiler/main/Packages.lhs
./compiler/main/PackageConfig.hs
./compiler/main/Finder.lhs

(plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs)

The ones in GHC core seem to rely only on quite basic data types.

 From this, I would boldly claim that people have spent more time making 
the GHC build system work with this Cabal dependency than it would take 
stripping it off!

(In fact, I would try to do this right now if the GHC build system 
wouldn't take so long to compile even the smallest changes ...)
Yuri de Wit | 6 Sep 16:22 2013
Picon

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

That's right, Roman, not knowing anything about it would be even better!

Here is the same dependency info in a different format.

I also noticed that cabal has a more complete implementation of Version. Couldn't this also move/merged with base (I think there is already a Version module in base or something like that).




On Fri, Sep 6, 2013 at 10:17 AM, Niklas Hambüchen <mail <at> nh2.me> wrote:
On Fri 06 Sep 2013 22:52:40 JST, Roman Cheplyaka wrote:
> The right solution for Cabal would be not to know anything about the
> GHC's database format at all.
>
> GHC and cabal communicate via a command line interface (`ghc-pkg dump`
> in our direction; `ghc-pkg update` in the other). So it would suffice to
> have a library which implements parsing and printing of the package
> description, and have that library shared between GHC and Cabal.

You are right. This is better.

GHC's dependency on cabal seems to actually be quite minimal!

I did a quick grep:

% grep -rI "import Distribution" --include "*.hs" --include "*.lhs*" .
| grep -v "libraries/" | grep -v Setup.hs | grep -v Setup.lhs | grep -v
utils/haddock
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Check
hiding (doesFileExist)
./utils/ghc-cabal/Main.hs:import
Distribution.PackageDescription.Configuration
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Parse
./utils/ghc-cabal/Main.hs:import Distribution.System
./utils/ghc-cabal/Main.hs:import Distribution.Simple
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Configure
./utils/ghc-cabal/Main.hs:import Distribution.Simple.LocalBuildInfo
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program.HcPkg
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Utils
(defaultPackageDesc, writeFileAtomic, toUTF8)
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Build
(writeAutogenFiles)
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Register
./utils/ghc-cabal/Main.hs:import Distribution.Text
./utils/ghc-cabal/Main.hs:import Distribution.Verbosity
./utils/ghctags/Main.hs:import Distribution.Simple.GHC (
componentGhcOptions )
./utils/ghctags/Main.hs:import Distribution.Simple.Configure (
getPersistBuildConfig )
./utils/ghctags/Main.hs:import Distribution.Simple.Compiler (
compilerVersion )
./utils/ghctags/Main.hs:import Distribution.Simple.Program.GHC (
renderGhcOptions )
./utils/ghctags/Main.hs:import Distribution.PackageDescription (
library, libBuildInfo )
./utils/ghctags/Main.hs:import Distribution.Simple.LocalBuildInfo
./utils/ghc-pkg/Main.hs:import
Distribution.InstalledPackageInfo.Binary()
./utils/ghc-pkg/Main.hs:import Distribution.ModuleName hiding (main)
./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo
./utils/ghc-pkg/Main.hs:import Distribution.Compat.ReadP
./utils/ghc-pkg/Main.hs:import Distribution.ParseUtils
./utils/ghc-pkg/Main.hs:import Distribution.Package hiding (depends)
./utils/ghc-pkg/Main.hs:import Distribution.Text
./utils/ghc-pkg/Main.hs:import Distribution.Version
./compiler/ghci/Linker.lhs:import Distribution.Package hiding (depends,
PackageId)
./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo
./compiler/main/Packages.lhs:import
Distribution.InstalledPackageInfo.Binary
./compiler/main/Packages.lhs:import Distribution.Package hiding
(PackageId,depends)
./compiler/main/PackageConfig.hs:import
Distribution.InstalledPackageInfo
./compiler/main/PackageConfig.hs:import Distribution.ModuleName
./compiler/main/PackageConfig.hs:import Distribution.Package hiding
(PackageId)
./compiler/main/PackageConfig.hs:import Distribution.Text
./compiler/main/PackageConfig.hs:import Distribution.Version
./compiler/main/Finder.lhs:import Distribution.Text
./compiler/main/Finder.lhs:import Distribution.Package hiding
(PackageId)

As you can see, there are only 4 files in ghc itself that depend on
Cabal:

./compiler/ghci/Linker.lhs
./compiler/main/Packages.lhs
./compiler/main/PackageConfig.hs
./compiler/main/Finder.lhs

(plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs)

The ones in GHC core seem to rely only on quite basic data types.

 From this, I would boldly claim that people have spent more time making
the GHC build system work with this Cabal dependency than it would take
stripping it off!

(In fact, I would try to do this right now if the GHC build system
wouldn't take so long to compile even the smallest changes ...)

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Herbert Valerio Riedel | 6 Sep 16:32 2013
Picon

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote:
> I spent some time looking into the touch points between ghc and cabal in
> the past, and the first oddity i saw was a direct dependency from ghc to
> the cabal sources. After taking a closer look it seems that ghc shares some
> common, low level modules with cabal that didnt seem to justify the whole
> dependency.
>
> The right solution, imho, is to review these dependencies and move the low
> level ones out into a separate package that is shared by both ghc and cabal
> and that will rarely change. The direct side effect of this is that ghc
> would not be tied directly to a specific cabal version and you would
> not have to deal with this issue.

[...]

fyi, a similiar/related discussion took place few months ago on ghc-devs:

 http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html

hth,
  hvr
JP Moresmau | 6 Sep 16:52 2013
Picon

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

Interesting: in the ghc-devs discussion, Duncan talks about a cabal-lib and a cabal-build-simple split (http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html). That would solve my problem nicely (GHC could depend on cabal-lib only, that wouldn't have to change as often as cabal-build-simple). I don't see a trace of that split in 1.18, anybody knows if it's still on the map?
And thanks everybody for the contributions, it looks I'm not the only one that had thought about that issue...

JP


On Fri, Sep 6, 2013 at 4:32 PM, Herbert Valerio Riedel <hvr <at> gnu.org> wrote:
On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote:
> I spent some time looking into the touch points between ghc and cabal in
> the past, and the first oddity i saw was a direct dependency from ghc to
> the cabal sources. After taking a closer look it seems that ghc shares some
> common, low level modules with cabal that didnt seem to justify the whole
> dependency.
>
> The right solution, imho, is to review these dependencies and move the low
> level ones out into a separate package that is shared by both ghc and cabal
> and that will rarely change. The direct side effect of this is that ghc
> would not be tied directly to a specific cabal version and you would
> not have to deal with this issue.

[...]

fyi, a similiar/related discussion took place few months ago on ghc-devs:

 http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html

hth,
  hvr



--
JP Moresmau
http://jpmoresmau.blogspot.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Niklas Hambüchen | 6 Sep 17:06 2013

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

We just had a short discussion on #ghc, I copy-paste:

http://lpaste.net/92639

dcoutts_: nh2: Cabal does not depend on the ghc-pkg format. Cabal
specifies a compiler-independent package registration format. GHC uses
it in its external interface (and internally too). It uses the Cabal lib
for the parser+printer because it's easier than making its own and
keeping up with spec changes..
dcoutts_: type+parser+printer
nh2: dcoutts_: would it still not be easier to make this package
database specification a separate thing that both ghc and cabal can
depend on? It seems to me that this would be much less a moving target
than Cabal-the-build-system is
dcoutts_: nh2: what does make sense is to split the Cabal lib into the
Distribution.* bits and the Distribution.Simple.* bits
dcoutts_: nh2: it's not a natural split
hvr: nh2: btw, a related thread:
http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html
dcoutts_: nh2: there's a lot of types shared between the .cabal format
and the InstalledPackageInfo type
dcoutts_: as well as parser + printer infrastructure
dcoutts_: nh2: it makes sense to keep that all together, that's the
Distribution.* stuff
dcoutts_: as I said, what does make sense to split (it's been
deliberately kept mostly-separate) is the Distribution.Simple.* part
dcoutts_: nh2: and we need a parser for that part, that's the dependency
that's annoying
thoughtpolice: so yes, i'm going to look into it today if at all possible
nh2: dcoutts_: that makes sense. ghc does not depend on
Distribution.PackageDescription either, right?
dcoutts_: nh2: right, it doesn't need the source package type
(PackageDescription), just the installed package type (InstalledPackageInfo)
dcoutts_: nh2: but splitting these into different packages would not buy
us much and it's not a natural split
nh2: leaving away Distribution.Simple.*, the remaining part is already
so small that it indeed looks like a small enough interface
dcoutts_: nh2: it'd only help JP M if the remaining part (lets call it
cabal-build-simple) could build with an earlier core part (lets call it
cabal-lib) (in his request in
http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html)
dcoutts_: nh2: and doesn't help me with my parser problems, we still
cannot depend on a decent parser combinator lib
dcoutts_: still have to use the crappy ReadP
nh2: dcoutts_: Distribution.PackageDescription is the .cabal file format
itself, right? Not sure if that should be part of the package DB spec,
it changes more often and ghc can't make use of it
nh2: why is it that you cannot depend on something better?
dcoutts_: nh2: because ghc cannot depend on parsec easily
dcoutts_: because it pulls in too many other things
dcoutts_: the ghc devs objected to my suggestion
dcoutts_: nh2: that's true but what does it really buy us if they're in
separate packages? We still cannot guarantee to support JP M's request
dcoutts_: e.g. in the switch to 1.18, there have been enough changes
that we'd need the latest version of the InstalledPackageInfo
hvr: dcoutts_: ...seems you have to explain that again everytime
somebody brings it up =)
nh2: dcoutts_: but do I not understand it right that if you put
PackageDescription not into cabal-lib and only in Cabal, Cabal could
actually depend on a proper parser since GHC doesn't depend on it any more?
dcoutts_: nh2: it's not a monolithic parser
dcoutts_: nh2: we have that Text class
dcoutts_: with the combinator parsers for all the various types used in
.cabal and installed package files
dcoutts_: these types + parser/printer infrastructure are shared between
the source and installed package files
dcoutts_: so even if we split it, we still have the problem of needing a
parser lib
lemao: dcoutts_: I hear you wrt to the difficulties and mixed results of
splitting Distribution.Simple at the same time that this GHC dependency
on cabal is really problematic for all the reasons already discussed
dcoutts_: lemao: I don't think splitting it would fix that
lemao: dcoutts_: yes, I hear you. Maybe the right solution here is to
have GHC own their own internal package info impl so Cabal and GHC can
go their separate ways
dcoutts_: you'd still have ghc depending on this smaller part, and
Cabal/cabal-install would still depend on (usually) the latest version
of that
dcoutts_: lemao: but that's also not satisfactory (for cabal-lib to be a
private dep of ghc) because ghc api exposes the InstalledPackageInfo type
dcoutts_: it's not a private dependency of the ghc api package, it's a
public dependency
lemao: dcoutts_: I guess what I meant is that ghc-pkg package
format/parser/etc would be a complete fork
dcoutts_: which then means you cannot pass the InstalledPackageInfo from
ghc api functions to anything else
lemao: dcoutts_: at the same time that there are issues with the split
there are real issues witht he current status quo
dcoutts_: as well as meaning it'd get out of sync
nh2: dcoutts_: InstalledPackageInfo looks like a very
simple/straightforward type though
dcoutts_: nh2: on it's own, but it uses a bunch of other types + their
parsers+printers
dcoutts_: nh2: and are we really saying that we could always work with
old versions of this type, that we'd never need to depend on the latest
version in the latest version of Cabal?
dcoutts_: because if not, then we gain nothing
lemao: dcoutts_, nh2: real question here, how often does the package
info that matters for ghc actually changed in the past?
dcoutts_: lemao: it does change occasionally
dcoutts_: and it will change again
dcoutts_: we have changes pending
lemao: dcoutts_, nh2: I can see how most of the drivers for these
changes come from cabal
nh2: dcoutts_: I can't see many other types, there are only two: License
(a simple enum) and Version. Everything else is String/Bool
dcoutts_: nh2: PackageName, PackageId etc
nh2: dcoutts_: are both string newtypes
dcoutts_: nh2: but note also that it uses the same parser infrastructure
nh2: dcoutts_: would you mind if I open a bug to discuss this?
lemao: nh2: maybe what is needed here is a concrete proposal
lemao: nh2: so this can be discussed in more detail?
lemao: nh2: I guess a ticket would be a great start

On 06/09/13 23:52, JP Moresmau wrote:
> Interesting: in the ghc-devs discussion, Duncan talks about a cabal-lib
> and a cabal-build-simple split
> (http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html). That
> would solve my problem nicely (GHC could depend on cabal-lib only, that
> wouldn't have to change as often as cabal-build-simple). I don't see a
> trace of that split in 1.18, anybody knows if it's still on the map?
> And thanks everybody for the contributions, it looks I'm not the only
> one that had thought about that issue...
Alejandro Serrano Mena | 6 Sep 16:54 2013
Picon

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

I'm willing to help in the process, if some directions were given to me on how to tackle this problem.

In any case, for me is seems fine to have a dependency from cabal to ghc, the only problem is the converse: ghc depending on cabal. Is this right?


2013/9/6 Herbert Valerio Riedel <hvr <at> gnu.org>
On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote:
> I spent some time looking into the touch points between ghc and cabal in
> the past, and the first oddity i saw was a direct dependency from ghc to
> the cabal sources. After taking a closer look it seems that ghc shares some
> common, low level modules with cabal that didnt seem to justify the whole
> dependency.
>
> The right solution, imho, is to review these dependencies and move the low
> level ones out into a separate package that is shared by both ghc and cabal
> and that will rarely change. The direct side effect of this is that ghc
> would not be tied directly to a specific cabal version and you would
> not have to deal with this issue.

[...]

fyi, a similiar/related discussion took place few months ago on ghc-devs:

 http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html

hth,
  hvr

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Yuri de Wit | 6 Sep 17:00 2013
Picon

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

Alejandro,
 
that is correct, as I see it. Duncan has very good points there but it seems to me that we need a concrete proposal so we can propose solutions to the problem. The fact is that the current situation is a middle of the ground that doesn't help Cabal nor Ghc.




On Fri, Sep 6, 2013 at 10:54 AM, Alejandro Serrano Mena <trupill <at> gmail.com> wrote:
I'm willing to help in the process, if some directions were given to me on how to tackle this problem.

In any case, for me is seems fine to have a dependency from cabal to ghc, the only problem is the converse: ghc depending on cabal. Is this right?


2013/9/6 Herbert Valerio Riedel <hvr <at> gnu.org>
On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote:
> I spent some time looking into the touch points between ghc and cabal in
> the past, and the first oddity i saw was a direct dependency from ghc to
> the cabal sources. After taking a closer look it seems that ghc shares some
> common, low level modules with cabal that didnt seem to justify the whole
> dependency.
>
> The right solution, imho, is to review these dependencies and move the low
> level ones out into a separate package that is shared by both ghc and cabal
> and that will rarely change. The direct side effect of this is that ghc
> would not be tied directly to a specific cabal version and you would
> not have to deal with this issue.

[...]

fyi, a similiar/related discussion took place few months ago on ghc-devs:

 http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html

hth,
  hvr

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
JP Moresmau | 6 Sep 17:04 2013
Picon

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

Oh, I'm happy to help as well if somebody is needed to do the change, since I have much to win in the future if EclipseFP can take advantage of a new version of Cabal without having to wait for a new GHC. The split in two libraries that Duncan mentions seems the best approach to me, having InstalledPackageInfo and related classes + parsers + pretty printers available as one reasonably stable library, while having another one for the real Cabal functionality...

JP


On Fri, Sep 6, 2013 at 5:00 PM, Yuri de Wit <ydewit <at> gmail.com> wrote:
Alejandro,
 
that is correct, as I see it. Duncan has very good points there but it seems to me that we need a concrete proposal so we can propose solutions to the problem. The fact is that the current situation is a middle of the ground that doesn't help Cabal nor Ghc.




On Fri, Sep 6, 2013 at 10:54 AM, Alejandro Serrano Mena <trupill <at> gmail.com> wrote:
I'm willing to help in the process, if some directions were given to me on how to tackle this problem.

In any case, for me is seems fine to have a dependency from cabal to ghc, the only problem is the converse: ghc depending on cabal. Is this right?


2013/9/6 Herbert Valerio Riedel <hvr <at> gnu.org>
On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote:
> I spent some time looking into the touch points between ghc and cabal in
> the past, and the first oddity i saw was a direct dependency from ghc to
> the cabal sources. After taking a closer look it seems that ghc shares some
> common, low level modules with cabal that didnt seem to justify the whole
> dependency.
>
> The right solution, imho, is to review these dependencies and move the low
> level ones out into a separate package that is shared by both ghc and cabal
> and that will rarely change. The direct side effect of this is that ghc
> would not be tied directly to a specific cabal version and you would
> not have to deal with this issue.

[...]

fyi, a similiar/related discussion took place few months ago on ghc-devs:

 http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html

hth,
  hvr

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
JP Moresmau
http://jpmoresmau.blogspot.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Niklas Hambüchen | 6 Sep 17:19 2013

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

I have filed a GHC ticket under

http://ghc.haskell.org/trac/ghc/ticket/8244

I hope this way we can find a solution soon.

On 07/09/13 00:04, JP Moresmau wrote:
> Oh, I'm happy to help as well if somebody is needed to do the change,
> since I have much to win in the future if EclipseFP can take advantage
> of a new version of Cabal without having to wait for a new GHC. The
> split in two libraries that Duncan mentions seems the best approach to
> me, having InstalledPackageInfo and related classes + parsers + pretty
> printers available as one reasonably stable library, while having
> another one for the real Cabal functionality...
Niklas Hambüchen | 6 Sep 17:23 2013

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

It looks to me that technically it should be easy to split off the part
required by GHC.

Maybe somebody could just try that (currently it does not seem to take
longer than a few hours) so that we have some basic proposal and momentum.

On 07/09/13 00:04, JP Moresmau wrote:
> Oh, I'm happy to help as well if somebody is needed to do the change
JP Moresmau | 7 Sep 11:24 2013
Picon

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

I'll be happy to give it a shot!

JP


On Fri, Sep 6, 2013 at 5:23 PM, Niklas Hambüchen <mail <at> nh2.me> wrote:
It looks to me that technically it should be easy to split off the part
required by GHC.

Maybe somebody could just try that (currently it does not seem to take
longer than a few hours) so that we have some basic proposal and momentum.

On 07/09/13 00:04, JP Moresmau wrote:
> Oh, I'm happy to help as well if somebody is needed to do the change



--
JP Moresmau
http://jpmoresmau.blogspot.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Niklas Hambüchen | 7 Sep 12:17 2013

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

Would you mind hanging around in #ghc when working on it?

A few people found this interesting, so this might be useful to avoid 
duplicate effort.

On Sat 07 Sep 2013 18:24:43 JST, JP Moresmau wrote:
> I'll be happy to give it a shot!
Yuri de Wit | 11 Sep 16:11 2013
Picon

Re: GHC API + Cabal API + Cabal version checks: is there a way out?

That is a good point. I am usually there in #ghc with nickname lemao. Niklas is nh2 afaik.



On Sat, Sep 7, 2013 at 7:17 AM, Niklas Hambüchen <mail <at> nh2.me> wrote:
Would you mind hanging around in #ghc when working on it?

A few people found this interesting, so this might be useful to avoid
duplicate effort.

On Sat 07 Sep 2013 18:24:43 JST, JP Moresmau wrote:
> I'll be happy to give it a shot!


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane