Janek S. | 12 Dec 18:01 2012
Picon

Can cabal be turned into a package manager?

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 people from doing exactly 
the same thing? Or are we just having non-technical problems like lack of money or developers?

Janek
Bardur Arantsson | 12 Dec 18:16 2012
Picon

Re: Can cabal be turned into a package manager?

On 12/12/2012 06:01 PM, 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?
> 
> 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?
> 

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.)
Andre Cunha | 12 Dec 18:51 2012
Picon

Re: Can cabal be turned into a package manager?

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 <spam <at> scientician.net> wrote:
On 12/12/2012 06:01 PM, 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?
>
> 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?
>

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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Andre Cunha

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Brandon Allbery | 12 Dec 20:59 2012
Picon

Re: Can cabal be turned into a package manager?

On Wed, Dec 12, 2012 at 12:51 PM, Andre Cunha <andrecunha.usp <at> gmail.com> 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; Ruby programmers use RVM (think virthualenv) religiously to avoid "gem hell", and every Ruby project effectively has its own Ruby installation as a result.  Indeed, gem managers mostly expect you to be installing into private RVM sandboxes.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Rustom Mody | 13 Dec 07:12 2012
Picon

Re: Can cabal be turned into a package manager?

On Thu, Dec 13, 2012 at 1:29 AM, Brandon Allbery <allbery.b <at> gmail.com> wrote:
On Wed, Dec 12, 2012 at 12:51 PM, Andre Cunha <andrecunha.usp <at> gmail.com> 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 <es <at> ertes.de> 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-a-package-manager/  )

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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Badi' Abdul-Wahid | 13 Dec 19:16 2012
Picon

Re: Can cabal be turned into a package manager?

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 <rustompmody <at> gmail.com> wrote:
On Thu, Dec 13, 2012 at 1:29 AM, Brandon Allbery <allbery.b <at> gmail.com> wrote:
On Wed, Dec 12, 2012 at 12:51 PM, Andre Cunha <andrecunha.usp <at> gmail.com> 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 <es <at> ertes.de> 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-a-package-manager/  )

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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




--

Badi' Abdul-Wahid
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Rustom Mody | 14 Dec 18:10 2012
Picon

Re: Can cabal be turned into a package manager?



On Thu, Dec 13, 2012 at 11:46 PM, Badi' Abdul-Wahid <abdulwahidc <at> gmail.com> 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?
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Badi' Abdul-Wahid | 14 Dec 21:45 2012
Picon

Re: Can cabal be turned into a package manager?


On Fri, Dec 14, 2012 at 12:10 PM, Rustom Mody <rustompmody <at> gmail.com> wrote:
Do you know about emacs/ghci integration?
 
Cabal-install appears to have a --prefix flag, and running ghci with -package-db seems promising, eg
$ ghci -package-db dist/package.conf.inplace 

I'm still finding my way through the Haskell ecosystem myself, so I don't know yet how well this integrates with the rest of cabal-install-managed packages.

--

Badi' Abdul-Wahid
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Richard O'Keefe | 14 Dec 03:11 2012
Picon

Re: Can cabal be turned into a package manager?


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

> On Thu, Dec 13, 2012 at 1:29 AM, Brandon Allbery <allbery.b <at> gmail.com> wrote:
> On Wed, Dec 12, 2012 at 12:51 PM, Andre Cunha <andrecunha.usp <at> gmail.com> 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.
Ivan Perez | 16 Dec 12:10 2012
Picon

Re: Can cabal be turned into a package manager?

On 12 December 2012 18:16, Bardur Arantsson <spam <at> scientician.net> 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.
Ivan Perez | 16 Dec 12:24 2012
Picon

Re: Can cabal be turned into a package manager?

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 <ivanperezdominguez <at> gmail.com> wrote:
> On 12 December 2012 18:16, Bardur Arantsson <spam <at> scientician.net> 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.
Scott Lawrence | 12 Dec 18:16 2012
Picon

Re: Can cabal be turned into a package manager?

On Wed, 12 Dec 2012, 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?
>
> 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?

Linux package managers are so "good" at avoiding dependency hell because they 
don't have to - they fetch only from repositories that are carefully 
maintained and tested by humans, in a centralized fashion. The problem of 
handling dependencies in a purely automated fashion, with no concerted human 
effort, isn't solved by any of the major linux distros AFAIK.

Which isn't to say that I think it can't be solved; just that I don't know of 
any shining star we can use as an example.

(Incidentally, many linux distros package cabal packages with the same 
centralized-testing methodology under their own package repos, and it avoids 
dependency hell quite nicely. But I think there ought to be a better 
solution.)

>
> Janek
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

--

-- 
Scott Lawrence
Ertugrul Söylemez | 12 Dec 18:55 2012
Picon

Re: Can cabal be turned into a package manager?

"Janek S." <fremenzone <at> poczta.onet.pl> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Rustom Mody | 12 Dec 19:36 2012
Picon

Re: Can cabal be turned into a package manager?



On Wed, Dec 12, 2012 at 11:25 PM, Ertugrul Söylemez <es <at> ertes.de> wrote:
"Janek S." <fremenzone <at> poczta.onet.pl> 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!)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ertugrul Söylemez | 12 Dec 19:49 2012
Picon

Re: Can cabal be turned into a package manager?

Rustom Mody <rustompmody <at> gmail.com> wrote:

> On Wed, Dec 12, 2012 at 11:25 PM, Ertugrul Söylemez <es <at> ertes.de>
> wrote:
>
> > "Janek S." <fremenzone <at> poczta.onet.pl> 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!

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.

By the way, the Nix expressions can be derived from the Cabal
descriptions, at least for packages with the build type "Simple".  Even
for more complicated packages it should be very well possible.

> [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!)

It's commonly referred to as the "dependency hell".

Greets,
Ertugrul

--

-- 
Key-ID: E5DD8D11 "Ertugrul Soeylemez <es <at> ertes.de>"
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ivan Perez | 16 Dec 12:14 2012
Picon

Re: Can cabal be turned into a package manager?

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 <es <at> ertes.de> wrote:
> "Janek S." <fremenzone <at> poczta.onet.pl> 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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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

Gmane