Hi. I'm new here, so this may not be a good suggestion. 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. About multiple versions of the same gem: there is a gem called Bundler ( http://gembundler.com)? It allows you to create a Gemfile for your project, describing which gem and which version you need for your project to run. When you enter the command: $ bundle install It installs the required versions of the required gems, specified in your Gemfile. When you run: $ bundle exec <command> It runs the <command> using the specified version of each gem. So, you can keep multiple versions of the gems, and choose which one to use in a particular project. On 12 December 2012 15:16, Bardur Arantsson wrote:

...

In the recent months there was a lot of dicussion about cabal, dependency hell and alike. After reading some of these discussions there is a question I just have to ask:

Why not create a package manager (like rpm or apt) for Haskell software?

I've been using Linux for years. Software for Linux is mostly written in C and C++. There are thousands of libraries with lots of dependencies and yet: a) Linux distributions manage to have package repositories that are kept in a consistent state b) Linux package managers can avoid dependency hell, automatically update to new packages, etc. Linux people did it! Is there any technical issue that prevents Haskell

On 12/12/2012 06:01 PM, Janek S. wrote: people from doing exactly

...

the same thing? Or are we just having non-technical problems like lack of money or developers?

Well, one big issue is that Linux distribution packagers have control of the entire stack. A (hypothetical) Haskell package manager wouldn't.

Typical package managers also restrict you to exactly one version of any given package. This can be a severe limitation for developers.

(There are more issues.)

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

-- Andre Cunha

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

On Thu, Dec 13, 2012 at 11:46 PM, Badi' Abdul-Wahid wrote:

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

Thanks. modules looks quite low level. Better low level and working!! Do you know about emacs/ghci integration?

On 13/12/2012, at 7:12 PM, Rustom Mody wrote:

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]

Why rely on memory? The Algol-60 compiler Dijkstra worked on was for the Electrologica X1. "The basic X1 machine, fitting in a large writing desk, consisted of an arithmetic unit and several registers, in particular two 27-bit accumulators A and S, a condition register, an instruction register, and a 16-bit index register. A and S could be used together as a single double-length register for multiply and divide operations. The basic machine had a built-in 'live' (i.e. random-access) memory of 512 words of 28 bits (including 1 sign bit and 1 parity bit); and 700 words of 'dead' (i.e. read-only) memory. More memory could be added in separate storage cabinets, up to 32768 words, including additional read-only memory. Normally there was no magnetic drum, disk or other type of secondary memory (a magnetic drum was an optional extension, however)". [http://www.science.uva.nl/faculteit/museum/X1.php -- edited lightly] Apparently the actual machine the compiler was built on had 4 kilo-words. That compiler read the source paper tape exactly twice. "The greatest shortcoming of the system, however, was the almost complete absence of syntax checks and run–time checks", something that was to be repeated in the development of C. Another front end that did more thorough syntax checking was written a few years later; Lint saw _that_ part of Algol 60 history repeated too. A leaflet in my letterbox yesterday advertised a headless box with 16GB of memory for NZD 700. We've come a long way.

Btw, one more great pearl of Gentoo's package manager: predependencies and postdependencies. These are packages (and/or programs) that must be installed in the system prior to the package being installed, and after the package is installed, respectively. Most packages have almost the same predeps, deps and postdeps. A Haskell compiler might be a (pre-)dependency for most packages, but not necessarily a post-dependency. Gtk should have "gtk2hs-buildtools" in its predependencies, but not in its postdependencies (once the package is installed, gtk2hs-buildtools is not needed anymore). The same is true for many packages that depend on happy, alex, etc. If your program needs an auxiliary program to run, but needs not be compiled against it, that's also the place for predeps/postdeps. I used it for a long time (not anymore), and it works wonders. It would be great to have something like this in cabal. On 16 December 2012 12:10, Ivan Perez wrote:

On 12 December 2012 18:16, Bardur Arantsson wrote:

...

On 12/12/2012 06:01 PM, Janek S. wrote:

Well, one big issue is that Linux distribution packagers have control of the entire stack. A (hypothetical) Haskell package manager wouldn't.

In Gentoo, there are many package overlays apart from the main repository. You can add as many as you want (local or remote).

...

Typical package managers also restrict you to exactly one version of any given package. This can be a severe limitation for developers.

Gentoo's emerge doesn't. It adds a concept called slots, which are different versions of the same package that can be installed in the same system without conflict. While this property is true for most versions of most packages in hackage, it is not necessarily true if those packages contain executables.

On Wed, Dec 12, 2012 at 11:25 PM, Ertugrul Söylemez wrote:

"Janek S." wrote:

...

In the recent months there was a lot of dicussion about cabal, dependency hell and alike. After reading some of these discussions there is a question I just have to ask:

Why not create a package manager (like rpm or apt) for Haskell software?

There is no need to reinvent that. See below.

...

I've been using Linux for years. Software for Linux is mostly written in C and C++. There are thousands of libraries with lots of dependencies and yet: a) Linux distributions manage to have package repositories that are kept in a consistent state b) Linux package managers can avoid dependency hell, automatically update to new packages, etc. Linux people did it! Is there any technical issue that prevents Haskell people from doing exactly the same thing? Or are we just having non-technical problems like lack of money or developers?

Actually Linux distributions do all the hard work for you. Package maintainers know what I'm talking about. It's a difficult task to specify correct dependencies, tedious to negotiate with all the other developers and all in all provide a consistent system. But that's only half of the story.

The problem starts with the File Hierarchy Standard (FHS), which essentially doesn't allow you to employ a more useful concept. That's why an experimental (yet quite usable) Linux distribution called NixOS [1] has established. It recognizes the problems of the FHS. The solution is simple and radical: the FHS sucks, so ignore it.

NixOS uses the Nix package manager, which you can also use for your Haskell packages to escape from the dependency hell. With Nix you can even allow all users to install arbitrary packages without interfering with other users, even the same packages with different versions. Two programs can depend on different versions of the same library, etc. It's the package manager of the future. Unfortunately the concept is new and different enough that it will be difficult to convince a large portion of the Linux community to employ it. It's the same issue Haskell has in the programming language world.

There is no need to switch to NixOS to use Nix. You can even install it in your home directory.

[1]: http://nixos.org/

Thanks Ertugrul for mentioning nix. My initial study of nix looked very promising as a solution to cabal-hell[2] but it seemed to suggest that one needs to change the whole OS! I must say that I am still dilly-dallying between cabal-dev virthualenv and nix and would appreciate a push! [2] I believe that saying cabal-hell is part of the problem with cabal-hell. A more correct phrase may be "Haskell-has-no-standardized-package-manager-hell" (which is a bit long!)

Well, one advantage of cabal over nix is that cabal works on windows. I haven't tried to install nix on windows, but: "Portability. Nix should run on most Unix systems, including Linux, FreeBSD and Mac OS X." Has anyone tried it? Cheers, Ivan On 12 December 2012 18:55, Ertugrul Söylemez wrote:

"Janek S." wrote:

...

In the recent months there was a lot of dicussion about cabal, dependency hell and alike. After reading some of these discussions there is a question I just have to ask:

Why not create a package manager (like rpm or apt) for Haskell software?

There is no need to reinvent that. See below.

...

I've been using Linux for years. Software for Linux is mostly written in C and C++. There are thousands of libraries with lots of dependencies and yet: a) Linux distributions manage to have package repositories that are kept in a consistent state b) Linux package managers can avoid dependency hell, automatically update to new packages, etc. Linux people did it! Is there any technical issue that prevents Haskell people from doing exactly the same thing? Or are we just having non-technical problems like lack of money or developers?

Actually Linux distributions do all the hard work for you. Package maintainers know what I'm talking about. It's a difficult task to specify correct dependencies, tedious to negotiate with all the other developers and all in all provide a consistent system. But that's only half of the story.

The problem starts with the File Hierarchy Standard (FHS), which essentially doesn't allow you to employ a more useful concept. That's why an experimental (yet quite usable) Linux distribution called NixOS [1] has established. It recognizes the problems of the FHS. The solution is simple and radical: the FHS sucks, so ignore it.

NixOS uses the Nix package manager, which you can also use for your Haskell packages to escape from the dependency hell. With Nix you can even allow all users to install arbitrary packages without interfering with other users, even the same packages with different versions. Two programs can depend on different versions of the same library, etc. It's the package manager of the future. Unfortunately the concept is new and different enough that it will be difficult to convince a large portion of the Linux community to employ it. It's the same issue Haskell has in the programming language world.

There is no need to switch to NixOS to use Nix. You can even install it in your home directory.

[1]: http://nixos.org/

Greets, Ertugrul

-- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.

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