On Fri, 10 Jun 2011 08:56:57 -0400, Brad Chapman wrote:
Ketil, Christian and Antoine;
> sure, it should be no problem talking about this. I have, however,
no
> experience with cloud-based computing -- I prefer local clusters,
> where we have greater control over what is going on.
I currently use local machinery as well, for practical and political
reasons. I do think cloud (that is infrastructure-as-a-service)
would be
great for a lot of stuff, though.
Despite the name there isn't much cloud specific about
CloudBioLinux. It is a framework to install packages and will work
on local machines as well as on Amazon instances. What the cloud
provides is a lot of bare bone machines and need bootstrapping, and
a nice way to make the results of that bootstrapping and
installation available.
With the framework you can do:
fab -f fabfile.py -H localhost install_libraries:haskell
to install all of the defined Haskell packages on a local machine.
Actually, that would make this /much/ more useful, not being
cloud-bound. I'll forward it to some of our guys as well.
> An idea for big Haskell installations is to proxy hackage. Almost
> everything comes from hackage... but feel free to talk about
anything
All you need is a network connection, a working, recentish ghc, and
a
working cabal-install - everything else is then available on-demand.
Perfect. I just re-did the Haskell part of the install to have a
working cabal, which had fell by the wayside at some point.
Hopefully the version that ships with Ubuntu is recent enough:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
My comment towards a proxy hackage is mainly because of scaling. If you
only compile on one machine and have static binaries -- which you
typically have; you do not need it. But several dozen or hundred
machines requiring hackage access would benefit. Though I guess this is
not the case here; but see below for more comments.
> I regard both my and Ketils libraries as "too unstable" to
pre-include
> them into a ready-to-use package. "Unstable" here basically means
that
> we change things too often; though Ketils is already nicely
> stable. But if a tool like cabal-dev is available, that is of no
big
> concern anyway.
I do have a bunch of tools that are reasonably stable, and I run
weekly
tests to ensure that they compile against current hackage.
"My" library is a little bit of everything - some stuff is used all
over
the place, some has little use but extensive testing, some is just
experimental. One option - part of the "biocore" effort - could be
to
factor out the stable and well tested stuff.
What I'd really like to get is just a set of the most useful
packages a Haskell bioinformatics/statistical programmer would want
around. For instance, for Python I'd be disappointed if I worked on
a system that claimed to have support for doing Python in
bioinformatics and it didn't have Numpy or Biopython. Here's my
initial start:
https://github.com/chapmanb/cloudbiolinux/blob/master/config/haskell-libs.yaml
I still propose to install the haskell-platform -- and only the Haskell
platform. This is basically what I mean with stable, packages included
in the platform are "stable" everything else is not. For "bio", Ketil
has to say what he thinks, but "Biobase" should never ever be part of
such a pre-installed system. I change something almost every day and
break backward- and forward-compatibility one or twice per week.
My workflow is basically like this:
- have the Haskell platform installed (everywhere, not that important
right now as haskell builds big static blobs)
- on the development machine "cabal-dev" provides a localized build
environment which uses the per-system haskell-platform but has
per-project additional dependencies
- compiled binaries are started on the cluster
Having faster-changing libraries pre-installed would be /extremely/
problematic due to multiple versions clashing, etc...
But then again, a Haskell developer can be much more lenient with what
he needs. A simple "cabal-dev install-deps" will grab everything I need
for my current project with all dependencies correctly solved.
Thanks much for all the ideas,
Brad
_______________________________________________
Biohaskell mailing list
Biohaskell@biohaskell.org
http://malde.org/cgi-bin/mailman/listinfo/biohaskell
_______________________________________________
Biohaskell mailing list
Biohaskell@biohaskell.org
http://malde.org/cgi-bin/mailman/listinfo/biohaskell
