cabal-install profiling libraries
Here's another instance of the machine (*) telling me what to do, instead of doing it (or am I missing something): I have a large set of cabal packages installed with ghc. Then suddenly I need some package Foo with profiling. So I switch to library-profiling: True in my .cabal/config, and then "cabal install Foo" - failing with the message: Perhaps you haven't installed the profiling libraries for package `Bar' for some package Bar that Foo depends upon. - Dear Cabal: Yes! I know that I haven't installed them! I want you to install them for me! But it isn't listening ... (*) "machine" = everything in that metal box that was so expensive and has a lot of cables coming out, and ventilators running. Of course you know that I have the highest respect for the work of the cabal authors. I'm just suggesting that the above feature (auto-re-install dependencies) would be helpful. Perhaps it's already there? If not - would it be hard to specify? To build? Or would it have bad consequences? Is it "cabal upgrade --reinstall"? But that was deprecated? Here I really want "reinstall with exactly the same versions". Is it the problem that their sources may have vanished, meanwhile? Could it be solved by having "cabal install" storing a copy of the source package that it used? Thanks - J.W.
On 20 August 2010 14:20, Johannes Waldmann
Here's another instance of the machine (*) telling me what to do, instead of doing it (or am I missing something):
I have a large set of cabal packages installed with ghc. Then suddenly I need some package Foo with profiling. So I switch to library-profiling: True in my .cabal/config, and then "cabal install Foo" - failing with the message:
Perhaps you haven't installed the profiling libraries for package `Bar'
for some package Bar that Foo depends upon. - Dear Cabal: Yes! I know that I haven't installed them! I want you to install them for me! But it isn't listening ...
Of course you know that I have the highest respect for the work of the cabal authors. I'm just suggesting that the above feature (auto-re-install dependencies) would be helpful.
As usual the problem is lack of devevloper time to implement all these nice features we all want. http://hackage.haskell.org/trac/hackage/ticket/282
Perhaps it's already there? If not - would it be hard to specify? To build? Or would it have bad consequences?
From the ticket:
Our current thinking on this issue is that we should track each "way" separately. That is we should register profiling, vanilla and any other ways with ghc-pkg as independent package instances. This needs coordination with ghc since it means a change to the package registration information to include the way. The idea is that once we track each way separately then Cabal will know if the profiling way is installed or not and we can install the profiling instance if it is missing without messing up any existing instances.
Is it "cabal upgrade --reinstall"? But that was deprecated?
Yes, "upgrade" is deprecated, use "install" instead. (The meaning / behaviour of "upgrade" just sowed confusion.)
Here I really want "reinstall with exactly the same versions".
Use: cabal install --reinstall foo-x.y.z
Is it the problem that their sources may have vanished, meanwhile? Could it be solved by having "cabal install" storing a copy of the source package that it used?
No, the problem is we don't actually know if the profiling versions of libs are installed or not. The ghc-pkg database does not contain this information. Also, if we did know and started reinstalling packages, what happens if we get half way and fail, we'd have messed up existing installed working packages. Having profiling instances be separate will make it all much easier. Duncan
On Friday 20 August 2010 15:20:41, Johannes Waldmann wrote:
Here's another instance of the machine (*) telling me what to do, instead of doing it (or am I missing something):
I have a large set of cabal packages installed with ghc. Then suddenly I need some package Foo with profiling. So I switch to library-profiling: True in my .cabal/config, and then "cabal install Foo" - failing with the message:
Perhaps you haven't installed the profiling libraries for package `Bar'
for some package Bar that Foo depends upon. - Dear Cabal: Yes! I know that I haven't installed them! I want you to install them for me! But it isn't listening ...
The problem is that otherpackages may depend on them too, so when cabal automatically reinstalls, those can break. I don't think GHC can register a profiling version of the package and leave the vanilla package in peace, so then cabal can't just build the profiling lib and keep the old vanilla either.
(*) "machine" = everything in that metal box that was so expensive and has a lot of cables coming out, and ventilators running.
Of course you know that I have the highest respect for the work of the cabal authors. I'm just suggesting that the above feature (auto-re-install dependencies) would be helpful. Perhaps it's already there? If not - would it be hard to specify? To build? Or would it have bad consequences?
Is it "cabal upgrade --reinstall"? But that was deprecated?
cabal install --reinstall
Here I really want "reinstall with exactly the same versions". Is it the problem that their sources may have vanished, meanwhile? Could it be solved by having "cabal install" storing a copy of the source package that it used?
cabal keeps the tarballs of the packages, so that's not a problem.
Daniel Fischer
The problem is that otherpackages may depend on them too, so when cabal automatically reinstalls, those can break.
how can this be - if the re-installed package is compiled from the exact original source (as I just learned, cabal stores the sources)? or do you mean "the dependent packages must be recompiled" - well, then cabal could just do it? Of course I understand "lack of developer time". Could any of this be forked out as student projects? J.W.
On Fri, Aug 20, 2010 at 4:07 PM, Johannes Waldmann < waldmann@imn.htwk-leipzig.de> wrote:
Of course I understand "lack of developer time". Could any of this be forked out as student projects?
These kind of projects are perfect for Google Summer of Code. We had two Cabal projects this year (Hackage 2 and unit testing support). The next GSoC is quite far in the future (9 months or so) but if we created some well written proposals for Cabal features we'd like to see implemented well in time for next year's GSoC we could get some students to work on them. Cheers, Johan
Could any of this be forked out as student projects?
I will teach a course (Sept. - Jan.) that introduces Haskell (students know Java). Part of the coursework is a programming project. I could assign some cabal tickets - but perhaps that's a bit far-fetched (requires understanding of the ghc infrastructure - too time-consuming?) J.W.
On Fri, Aug 20, 2010 at 7:14 AM, Johan Tibell
On Fri, Aug 20, 2010 at 4:07 PM, Johannes Waldmann < waldmann@imn.htwk-leipzig.de> wrote:
Of course I understand "lack of developer time". Could any of this be forked out as student projects?
These kind of projects are perfect for Google Summer of Code. We had two Cabal projects this year (Hackage 2 and unit testing support).
The next GSoC is quite far in the future (9 months or so) but if we created some well written proposals for Cabal features we'd like to see implemented well in time for next year's GSoC we could get some students to work on them.
I would like to encourage this workflow. Plan the writeup, project specification and whatnot, as if you we are going to get GSoC students to do the work. In the best case, someone (anyone whether they are a GSoC student or not) comes along and says, "Oh, what a well written proposal. I'll go implement it!" In the worst case we never find anyone to implement the proposal, but this is the open source world and if something is really valuable someone usually comes by to implement it. On the downside, sometimes it's harder to specify in a document format the correct behavior / implementation of such features than actually implementing them. Eventually these documents could even help future generations of cabal devs understand why things are the way they are. Jason
Johannes Waldmann
Daniel Fischer
writes: The problem is that otherpackages may depend on them too, so when cabal automatically reinstalls, those can break.
how can this be - if the re-installed package is compiled from the exact original source (as I just learned, cabal stores the sources)?
or do you mean "the dependent packages must be recompiled" - well, then cabal could just do it?
The latter, except that cabal-install doesn't know what you have installed (it can only go on the information supplied by ghc-pkg for now).
Of course I understand "lack of developer time". Could any of this be forked out as student projects?
Some of it was forked out to a GSoC project (a testing hook). Otherwise, I'm sure Duncan et. al. will support good-quality patches that solve the various bugs/feature requests on the bug tracker. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
participants (6)
-
Daniel Fischer -
Duncan Coutts -
Ivan Lazar Miljenovic -
Jason Dagit -
Johan Tibell -
Johannes Waldmann