[Haskell-cafe] cabal-install profiling libraries

[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 ...

(*) "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.

[Duncan Coutts]

Post by Johannes Waldmann
Here's another instance of the machine (*) telling me what to do,
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,
 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

Post by Johannes Waldmann
Perhaps it's already there?
If not - would it be hard to specify? To build? Or would it have
bad consequences?

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.

Post by Johannes Waldmann
Is it "cabal upgrade --reinstall"? But that was deprecated?

Yes, "upgrade" is deprecated, use "install" instead. (The meaning /
behaviour of "upgrade" just sowed confusion.)

Post by Johannes Waldmann
Here I really want "reinstall with exactly the same versions".

Use: cabal install --reinstall foo-x.y.z

Post by Johannes Waldmann
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

[Daniel Fischer]

Post by Johannes Waldmann
Here's another instance of the machine (*) telling me what to do,
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,
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.

Post by Johannes Waldmann
(*) "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

Post by Johannes Waldmann
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.

[Johannes Waldmann]

Post by 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.

[Johan Tibell]

On Fri, Aug 20, 2010 at 4:07 PM, Johannes Waldmann <

Post by Johannes Waldmann
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

[Johannes Waldmann]

Post by Johannes Waldmann
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.

[Johannes Waldmann]

Post by Johannes Waldmann
I will teach a course (Sept. - Jan.)

noh, it's Oct. - Jan.

otherwise it'd be too much of a good thing ...

[Jason Dagit]

Post by Johan Tibell
On Fri, Aug 20, 2010 at 4:07 PM, Johannes Waldmann <

Post by Johannes Waldmann
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

[Ivan Lazar Miljenovic]

Post by Johannes Waldmann

Post by 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?

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).

Post by Johannes Waldmann
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.