
Just my two cents: Nix is great, Modules is not perfect, but it is good.
I think that Nix solves a lot of the problems, but will likely take a while
to be adopted.
I'm still exploring Nix and NixOS, but I have to say: I really like it.
I've found that a practical solution for my own development work has been
the modules project [1].
I'd describe it as a happy medium between manual software management and
Nix.
The upside is similar to that of Nix: software with conflicting
dependencies can coexist.
The downside is that there is no package management: everything needs to be
installed manually and configured with --prefix.
However, I've found that the advantages far outweigh the disadvantages.
For instance, tracking down a bug where software A which depends on B which
depends on C, but C1 conflicts with C2, C3... etc, and you need to test all
permutations.
In my case, package C was multiple versions of cuda: 3.2, 4.0, 4.1, and 5.0
Testing was, eg:
$ module load environment/A-1.0/B-2.0/cuda-4.0
$ ./runtest.sh
I'd really like to see if cabal is compatible with this setup. Hopefully
I'll have time in the next few weeks to look into it.
Quick example of a module file for gsl on my machine:
$ cat ~/privatemodules/gsl/1.15
#%Module
set name gsl
set version 1.15
set prefix /opt
set root $prefix/$name/$version
prepend-path PATH $root/bin
prepend-path INCLUDE $root/include
prepend-path LD_LIBRARY_PATH $root/lib
prepend-path DYLD_LIBRARY_PATH $root/lib
[1] http://modules.sourceforge.net/
On Thu, Dec 13, 2012 at 1:12 AM, Rustom Mody
On Thu, Dec 13, 2012 at 1:29 AM, Brandon Allbery
wrote: On Wed, Dec 12, 2012 at 12:51 PM, Andre Cunha
wrote: Janek, did you mean something like Rubygems (http://rubygems.org)? It manages the download, installation and manipulation of Ruby packages, called "gems". A gem can contain executable programs or libraries (just like traditional packages, like .rpm). Rubygems also handles dependencies between gems, and allows you to update them.
But doesn't solve the actual problem;
Considering that this question is such a FAQ, I believe it would be worthwhile discussing what we think the 'actual problem' is.
When Algol-60 was being implemented, the challenge was how to compile using only 2000 words of memory (or something as ridiculous as that). The solution was to make a compiler with 20-odd passes. [Sorry if the details are wrong; its from (neurological) memory]
Today not just compilers but databases are vying with each other to go back from disk to memory -- hardly surprising considering that a vanilla machine bought today has a TB of disk and GBs of memory.
In short the goal-posts shift with time and we need to readjust priorities accordingly.
For myself if the total disk usage of my haskell-related installation were to go up from being linear in the number of packages to quadratic, I am unlikely to care. Of course total naivete in package-management strategy may make it exponential which would make me sit up!
Reminds me of a restatement/corollary to Moore's law I recently saw: Programmers' cost increase exponentially with time.
Just alpha-rename 'programmer' to 'cabal-installer'
On Thu, Dec 13, 2012 at 12:19 AM, Ertugrul Söylemez
wrote: I'm afraid the burden is that you would have to write the necessary Nix expressions for your Haskell packages, so until we create a real Nix channel for Hackage the barrier to entry is high. But it's certainly possible as a community project.
I believe you are saying something significant here. Here's my rendering of it.
Currently we have a 'managed' hackage server talking to an unmanaged cabal client (in the sense of http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-... / )
We need to move to hackage talking to a managed (as with nix) client.
So what work is needed to make this happen?
-- http://www.the-magus.in http://blog.languager.org
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Badi' Abdul-Wahid