Re: [Haskell-cafe] [Haskell] JustHub 'Sherkin' Release
36 views
Skip to first unread message
Chris Dornan
Jun 14, 2012, 5:49:24 PM6/14/12
to Andres Löh, haskel...@haskell.org
[This discussion was started on the Haskell mailing list in response
to an announcement I made which you can read here
http://justhaskell.org/2012/06/13/announce-justhub-sherkin/
At issue is whether the JustHub Haskell distribution for Enterprise Linux
and
the hub hackage for sandboxing development projects and integrating multiple
GHC
tool chains is redundant because all of the functionality is covered by the
Nix Haskell distribution, allowing as they do multiple Nix Haskell releases
to
be deployed simultaneously.]
(cd = Chris Dornan, al = Andres Löh)
cd: > The key feature is the way it integrates the multiple tool
chains into
cd: > a single virtual tool chain with a sandboxing mechanism
provided by
cd: > the hub hackage.
cd: > I think the Nix distribution might be a natural fit for 'hub'
cd: > integration -- I would be happy to work with the Nix people on
that
cd: > (though it can't be right now).
al: If this adds anything in terms of functionality that Nix doesn't
already provide,
al: then I would be interested to know. From having a quick look at
your
al: announcements, it's not quite clear though if it does.
Hi Adres,
From the original announcement (on the above link):
The JustHub distribution is based on the Hub system for sandbox
development that allows each work tree to work in its own sandboxed
environment with a specific tool chain and a private user-package
database. All of the standard Haskell tools inter-operate cleanly
and
transparently with the sandboxes and operate in the normal way
outside
of them.
Sandboxed environments (hubs) can be shared between work trees as
well
as being (re)named, annotated, replicated, swapped, archived, locked
and removed. Proper package deletion with the option of garbage
collecting orphaned code and documentation is also supported.
Where is this functionality provided by Nix? These are the 'key features'
that I
emphasized in the clarification.
I have loaded GHC-7.4.1 platform and the GHC-7.0.4 into Nix and it installs
all of the ghc drivers
into a single bin directory in the user's profile. I am guessing that
running `ghc` will generally
get you the latest compiler you have installed (7.4.1 in my case); specific
releases can be
invoked with ghc-7.0.4, etc.
This hardly covers all of the above functionality!
I think the Nix distribution is excellent and I strongly agree with its
functional philosophy -- which
I think is the right way to distribute Haskell.
Quite related to this (in my mind anyway) are the user-level facilities for
managing the package
databases that each work tree uses -- the problems that cabal-dev was
created to solve. What I
have done is to create a system that manages the environment each source
work tree uses.
If you are in a 2012.2.0.0-based project work tree then the ghc-driver will
detect that and invoke
the right tools. The 2012.2 platform uses cabal-instal-0.14 and that is what
you will get when
you invoke cabal in such a work tree.
However in work trees based on earlier version of the compiler (e.g.,
GHC-7.2.2), cabal-install-0.10.2
will be used because cabal-install-0.14.0 doesn't interoperate very well
with cabal-0.10 and earlier
(see https://github.com/haskell/cabal/issues/932). Also in such a work tree
you will get all
of the tools that were shipped with the GHC-7.2.2 and all through issuing
the usual command
'ghc', 'ghci', 'ghc-pkg', etc).
Without some system to help the user invoke the right tools in the right
context, having to invoke
each version of the compiler explicitly can get awkward to use quite
quickly. Think about installing a
package into a 7.0.4-based work tree where 'ghc' runs version 7.4.1. Cabal
will reach for 7.4.1 unless
told otherwise. The only practical way to do this is to build a PATH where
the right tools get run on
the default commands ('ghc', 'ghc-pkg', etc), or equivalently use
intelligent drivers that make sure
the right tools get invoked (the method JustHub uses).
It is also sometimes helpful to be able to start from the minimal collection
of packages that you get with
compiler (sans platform packages) and build your collection from there. The
JustHub system allows
you to do this, even on installations that are working double time as
Haskell Platform instantiations.
Oftentimes less is more in working out the right package combination!
Production Haskell development requires this kind of control over the
environment, we have all been
doing this for years and it isn't technically difficult.
But frankly it sure is tedious, especially when you have worked with
something better. And it means that
everyone has to hand-build their own developments -- that is wasteful.
GHC+cabal do provide an awesome build system but the package management
mechanisms aren't as
easy to use as they could be. There is no proper mechanism for erasing
packages for instance (arguably
because it is meaningless -- reinforcing my point) and the mechanisms for
managing package databases
are inconsistent across the tools (differing between 'cabal' and
'ghc'/ghc-pkg') and not very friendly
(requiring the setting up of environment variables and the use of special
flags). I have also found it highly
useful to be able to name, replicate, archive and share environments between
different work trees
All of this together (including the missing bits) can make for quite a steep
learning curve for those
gearing up for writing production Haskell code, and it can get in the way to
a surprising degree even
for those that have been doing it for a while (or at least that has been my
experience).
You may dismiss that as pointless or irrelevant but it _is_ a large part of
what I am trying get right and it did
feature prominently in the announcement. I can see elements of this present
in the Nix distribution
and cabal-dev and similar tools. But our current standard tools don't make
it easy for a developers to
unpack a production work tree, ensure the relevant tool chain is installed
and just work with it in the
precise configuration it needs; each developer has to solve that for
themselves. I think the Nix functional
approach to distributions is definitely going in the right direction in
giving user better control over which
packages are installed but, unless I have missed something, I don't think it
is so definitive that there isn't
room for other developments.
Finally a couple of gripes with Nix as a replacement for JustHub. JustHub
has a special emphasis on
Enterprise Linux (RHEL/CentOS/SL) developers. Because the EL family of O/Ses
have such long lifetimes
for each O/S release they pose special problems. The GCC tools shipped with
RHEL5 are just too long in the
tooth for use with recent versions of GHC, which is why JustHub ships with
GCC-4.6.1 and binutils-2.21. As
we have seen the Nix Linux package doesn't work with CentOS 5 and I have
tried to get the Nix distribution
loaded onto an up-to-date CentOS 6 system. As far as I could tell that
required building the package manager
from source but the build failed with an opaque libtool-related message.
Because the RPMs are available
for Fedora that was much easier to use.
Also I could not determine which releases of GHC you are supporting. It
looks as the distribution is focused
on the Haskell Platform, in which case only those releases of GHC will be
available, when they get scheduled
for inclusion in the platform. This is a more selective collection than I am
aiming to provide with JustHub, but
perhaps more importantly, it makes it hard for anyone trying to get hold of
an older release of the compiler to find
it and load it into Nix.
Chris
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
to an announcement I made which you can read here
http://justhaskell.org/2012/06/13/announce-justhub-sherkin/
At issue is whether the JustHub Haskell distribution for Enterprise Linux
and
the hub hackage for sandboxing development projects and integrating multiple
GHC
tool chains is redundant because all of the functionality is covered by the
Nix Haskell distribution, allowing as they do multiple Nix Haskell releases
to
be deployed simultaneously.]
(cd = Chris Dornan, al = Andres Löh)
cd: > The key feature is the way it integrates the multiple tool
chains into
cd: > a single virtual tool chain with a sandboxing mechanism
provided by
cd: > the hub hackage.
cd: > I think the Nix distribution might be a natural fit for 'hub'
cd: > integration -- I would be happy to work with the Nix people on
that
cd: > (though it can't be right now).
al: If this adds anything in terms of functionality that Nix doesn't
already provide,
al: then I would be interested to know. From having a quick look at
your
al: announcements, it's not quite clear though if it does.
Hi Adres,
From the original announcement (on the above link):
The JustHub distribution is based on the Hub system for sandbox
development that allows each work tree to work in its own sandboxed
environment with a specific tool chain and a private user-package
database. All of the standard Haskell tools inter-operate cleanly
and
transparently with the sandboxes and operate in the normal way
outside
of them.
Sandboxed environments (hubs) can be shared between work trees as
well
as being (re)named, annotated, replicated, swapped, archived, locked
and removed. Proper package deletion with the option of garbage
collecting orphaned code and documentation is also supported.
Where is this functionality provided by Nix? These are the 'key features'
that I
emphasized in the clarification.
I have loaded GHC-7.4.1 platform and the GHC-7.0.4 into Nix and it installs
all of the ghc drivers
into a single bin directory in the user's profile. I am guessing that
running `ghc` will generally
get you the latest compiler you have installed (7.4.1 in my case); specific
releases can be
invoked with ghc-7.0.4, etc.
This hardly covers all of the above functionality!
I think the Nix distribution is excellent and I strongly agree with its
functional philosophy -- which
I think is the right way to distribute Haskell.
Quite related to this (in my mind anyway) are the user-level facilities for
managing the package
databases that each work tree uses -- the problems that cabal-dev was
created to solve. What I
have done is to create a system that manages the environment each source
work tree uses.
If you are in a 2012.2.0.0-based project work tree then the ghc-driver will
detect that and invoke
the right tools. The 2012.2 platform uses cabal-instal-0.14 and that is what
you will get when
you invoke cabal in such a work tree.
However in work trees based on earlier version of the compiler (e.g.,
GHC-7.2.2), cabal-install-0.10.2
will be used because cabal-install-0.14.0 doesn't interoperate very well
with cabal-0.10 and earlier
(see https://github.com/haskell/cabal/issues/932). Also in such a work tree
you will get all
of the tools that were shipped with the GHC-7.2.2 and all through issuing
the usual command
'ghc', 'ghci', 'ghc-pkg', etc).
Without some system to help the user invoke the right tools in the right
context, having to invoke
each version of the compiler explicitly can get awkward to use quite
quickly. Think about installing a
package into a 7.0.4-based work tree where 'ghc' runs version 7.4.1. Cabal
will reach for 7.4.1 unless
told otherwise. The only practical way to do this is to build a PATH where
the right tools get run on
the default commands ('ghc', 'ghc-pkg', etc), or equivalently use
intelligent drivers that make sure
the right tools get invoked (the method JustHub uses).
It is also sometimes helpful to be able to start from the minimal collection
of packages that you get with
compiler (sans platform packages) and build your collection from there. The
JustHub system allows
you to do this, even on installations that are working double time as
Haskell Platform instantiations.
Oftentimes less is more in working out the right package combination!
Production Haskell development requires this kind of control over the
environment, we have all been
doing this for years and it isn't technically difficult.
But frankly it sure is tedious, especially when you have worked with
something better. And it means that
everyone has to hand-build their own developments -- that is wasteful.
GHC+cabal do provide an awesome build system but the package management
mechanisms aren't as
easy to use as they could be. There is no proper mechanism for erasing
packages for instance (arguably
because it is meaningless -- reinforcing my point) and the mechanisms for
managing package databases
are inconsistent across the tools (differing between 'cabal' and
'ghc'/ghc-pkg') and not very friendly
(requiring the setting up of environment variables and the use of special
flags). I have also found it highly
useful to be able to name, replicate, archive and share environments between
different work trees
All of this together (including the missing bits) can make for quite a steep
learning curve for those
gearing up for writing production Haskell code, and it can get in the way to
a surprising degree even
for those that have been doing it for a while (or at least that has been my
experience).
You may dismiss that as pointless or irrelevant but it _is_ a large part of
what I am trying get right and it did
feature prominently in the announcement. I can see elements of this present
in the Nix distribution
and cabal-dev and similar tools. But our current standard tools don't make
it easy for a developers to
unpack a production work tree, ensure the relevant tool chain is installed
and just work with it in the
precise configuration it needs; each developer has to solve that for
themselves. I think the Nix functional
approach to distributions is definitely going in the right direction in
giving user better control over which
packages are installed but, unless I have missed something, I don't think it
is so definitive that there isn't
room for other developments.
Finally a couple of gripes with Nix as a replacement for JustHub. JustHub
has a special emphasis on
Enterprise Linux (RHEL/CentOS/SL) developers. Because the EL family of O/Ses
have such long lifetimes
for each O/S release they pose special problems. The GCC tools shipped with
RHEL5 are just too long in the
tooth for use with recent versions of GHC, which is why JustHub ships with
GCC-4.6.1 and binutils-2.21. As
we have seen the Nix Linux package doesn't work with CentOS 5 and I have
tried to get the Nix distribution
loaded onto an up-to-date CentOS 6 system. As far as I could tell that
required building the package manager
from source but the build failed with an opaque libtool-related message.
Because the RPMs are available
for Fedora that was much easier to use.
Also I could not determine which releases of GHC you are supporting. It
looks as the distribution is focused
on the Haskell Platform, in which case only those releases of GHC will be
available, when they get scheduled
for inclusion in the platform. This is a more selective collection than I am
aiming to provide with JustHub, but
perhaps more importantly, it makes it hard for anyone trying to get hold of
an older release of the compiler to find
it and load it into Nix.
Chris
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Simons
Jun 15, 2012, 4:36:08 AM6/15/12
to haskel...@haskell.org
Hi Chris,
> Where is this functionality provided by Nix?
simply run these commands
# Haskell Platform 2009.2.0.2
nix-env -p ~/ghc-6.10.4 -iA haskellPackages_ghc6104.haskellPlatform
# Haskell Platform 2010.2.0.0
nix-env -p ~/ghc-6.12.3 -iA haskellPackages_ghc6123.haskellPlatform
# Haskell Platform 2012.2.0.0'
nix-env -p ~/ghc-7.4.1 -iA haskellPackages_ghc741.haskellPlatform
and you'll have profiles that contain the appropriate binaries and
libraries defined by the corresponding platform. Nix can do this without
any superuser privileges on Linux, Darwin, and BSD Unix, although I have
to say that BSD support is limited because there seem to be very few
people using Nix on BSD. (I reckon the BSD people are happy with their
BSD ports and aren't interested in a third-party package manager.)
Furthermore, Nix can many different versions of *any* package
simultaneously, not just Haskell:
nix-env -p ~/python-2.6.7 -iA python26
nix-env -p ~/python-2.7.3 -iA python27
nix-env -p ~/python-3.2.3 -iA python3
Anyone who's interested in Nix can find lots of information on the web
site <http://nixos.org/>. There's also the IRC channel #nixos on
irc.freenode.org where some Nix developers hang out. Last but not least,
there is the developer mailing list <nix...@cs.uu.nl>.
I'll be happy to answer any further questions that may arise.
Take care,
Peter
> Where is this functionality provided by Nix?
# Haskell Platform 2009.2.0.2
nix-env -p ~/ghc-6.10.4 -iA haskellPackages_ghc6104.haskellPlatform
# Haskell Platform 2010.2.0.0
nix-env -p ~/ghc-6.12.3 -iA haskellPackages_ghc6123.haskellPlatform
# Haskell Platform 2012.2.0.0'
nix-env -p ~/ghc-7.4.1 -iA haskellPackages_ghc741.haskellPlatform
and you'll have profiles that contain the appropriate binaries and
libraries defined by the corresponding platform. Nix can do this without
any superuser privileges on Linux, Darwin, and BSD Unix, although I have
to say that BSD support is limited because there seem to be very few
people using Nix on BSD. (I reckon the BSD people are happy with their
BSD ports and aren't interested in a third-party package manager.)
Furthermore, Nix can many different versions of *any* package
simultaneously, not just Haskell:
nix-env -p ~/python-2.6.7 -iA python26
nix-env -p ~/python-2.7.3 -iA python27
nix-env -p ~/python-3.2.3 -iA python3
Anyone who's interested in Nix can find lots of information on the web
site <http://nixos.org/>. There's also the IRC channel #nixos on
irc.freenode.org where some Nix developers hang out. Last but not least,
there is the developer mailing list <nix...@cs.uu.nl>.
I'll be happy to answer any further questions that may arise.
Take care,
Peter
Chris Dornan
Jun 15, 2012, 6:50:26 AM6/15/12
to Peter Simons, haskel...@haskell.org
Hi Peter and Andres,
> > Where is this functionality provided by Nix?
>
> simply run these commands
>
> ...
appropriate platform. Unfortunately I cannot see how it can address any of
the
user-level Haskell package database management and sandboxing mechanisms
that
I mentioned in the announcement and subsequent emails.
Also it requires that the user load up a special environment before going to
work on a work tree rather than the drivers detecting from the context
the correct toolchain and invoking it automatically. It might not
sound like much but imagine how it would be if you had to set up a special
environment before you could work with a git work tree -- there is quite
a difference between the two approaches in practice.
Finally the Nix method is of course fundamentally dependent upon Nix.
I can appreciate why you may believe that everybody should just get Haskell
through Nix but I think there is merit to developing a mechanism that allows
Haskell to be better packaged regardless of its distribution channel. If
I thought there was any chance at all that Haskell could be universally
provided through Nix then it might be different, but I don't.
None of which detracts from general excellence of Nix and the Nix Haskell
distribution. And I still think the mechanism I am proposing would work well
with the Nix distribution. Indeed it may be best placed to make full use of
it.
Chris
> > Where is this functionality provided by Nix?
>
> simply run these commands
>
>
> # Haskell Platform 2012.2.0.0'
> nix-env -p ~/ghc-7.4.1 -iA haskellPackages_ghc741.haskellPlatform
>
> and you'll have profiles that contain the appropriate binaries and
libraries
> defined by the corresponding platform.
What you have here is a mechanism for setting up a user-environment for an
> # Haskell Platform 2012.2.0.0'
> nix-env -p ~/ghc-7.4.1 -iA haskellPackages_ghc741.haskellPlatform
>
> and you'll have profiles that contain the appropriate binaries and
libraries
> defined by the corresponding platform.
appropriate platform. Unfortunately I cannot see how it can address any of
the
user-level Haskell package database management and sandboxing mechanisms
that
I mentioned in the announcement and subsequent emails.
Also it requires that the user load up a special environment before going to
work on a work tree rather than the drivers detecting from the context
the correct toolchain and invoking it automatically. It might not
sound like much but imagine how it would be if you had to set up a special
environment before you could work with a git work tree -- there is quite
a difference between the two approaches in practice.
Finally the Nix method is of course fundamentally dependent upon Nix.
I can appreciate why you may believe that everybody should just get Haskell
through Nix but I think there is merit to developing a mechanism that allows
Haskell to be better packaged regardless of its distribution channel. If
I thought there was any chance at all that Haskell could be universally
provided through Nix then it might be different, but I don't.
None of which detracts from general excellence of Nix and the Nix Haskell
distribution. And I still think the mechanism I am proposing would work well
with the Nix distribution. Indeed it may be best placed to make full use of
it.
Chris
Peter Simons
Jun 15, 2012, 3:10:24 PM6/15/12
to haskel...@haskell.org
Hi Chris,
> I cannot see how it can address any of the user-level Haskell package
> database management and sandboxing mechanisms that I mentioned in the
> announcement and subsequent emails.
have you ever actually used Nix?
Take care,
Peter
> I cannot see how it can address any of the user-level Haskell package
> database management and sandboxing mechanisms that I mentioned in the
> announcement and subsequent emails.
Take care,
Peter
Chris Dornan
Jun 15, 2012, 3:20:08 PM6/15/12
to Peter Simons, haskel...@haskell.org
I deatiled some of my trials with Nix -- I wasn't making it up!
Chris
Chris
Krzysztof Skrzętnicki
Jun 15, 2012, 3:24:34 PM6/15/12
to Peter Simons, haskel...@haskell.org
To be honest I did try to use Nix for exactly this purpose. For some reason things started to break and since I couldnt find any documentation on how to do stuff with it, I just abandonded the idea. Also tried out NixOS: pretty much the same story. Everything appears to be fine at the start, but then after few upgrades things start to fail.
I know its very vague but really this is how I remember this experience. For one thing there was lack of "how tos" related to Haskell stuff anywhere. Just some general documentation that really have some gaps. You end up digging up some implementation details just because you wanted to install a new package.
I'm not trying to spread FUD: only telling my not-so-success story with Nix.
I'm sure Nix/NixOS has some potential but clearly it's not there yet for some reason.
Best regards,
Krzysztof Skrzętnicki
I know its very vague but really this is how I remember this experience. For one thing there was lack of "how tos" related to Haskell stuff anywhere. Just some general documentation that really have some gaps. You end up digging up some implementation details just because you wanted to install a new package.
I'm not trying to spread FUD: only telling my not-so-success story with Nix.
I'm sure Nix/NixOS has some potential but clearly it's not there yet for some reason.
Best regards,
Krzysztof Skrzętnicki
Peter Simons
Jun 15, 2012, 4:05:09 PM6/15/12
to haskel...@haskell.org
Hi Chris,
> I deatiled some of my trials with Nix -- I wasn't making it up!
of course, I didn't mean to imply that you were. My question was phrased
poorly, I am sorry.
What I meant to ask is: how much time, approximately, did you spend
working with Nix? 1 hour? 10 hours? 10 days? 10 months?
Take care,
Peter
> I deatiled some of my trials with Nix -- I wasn't making it up!
poorly, I am sorry.
What I meant to ask is: how much time, approximately, did you spend
working with Nix? 1 hour? 10 hours? 10 days? 10 months?
Take care,
Peter
Chris Dornan
Jun 15, 2012, 6:46:57 PM6/15/12
to Peter Simons, haskel...@haskell.org
> What I meant to ask is: how much time, approximately, did you spend
> working with Nix? 1 hour? 10 hours? 10 days? 10 months?
You know that it is not 10 months, but I do object to your line of questioning.
> working with Nix? 1 hour? 10 hours? 10 days? 10 months?
I have invested a considerable good-faith effort into getting to the
bottom of what
you and Andres have been saying. I am no seasoned expert at Nix but I have
been through the process of installing and using multiple distributions,
and reading around and I have been paying attention to what you have
been saying.
But my time is really quite limited.
I of course know exactly what I have been doing in putting together the JustHub
distribution and while they have some similarities -- mostly around the idea
of allowing multiple tool chains to co-exist; the way they go about it is very
different. And those details are critical in my mind (please note). I also know
that I have been adding things that a generic package manager is most
unlikely to be covering -- because a new tool is provided that tangles
with the existing
tools in a detailed way (e.g., parsing spec files and analysing
package databases
for example).
To take just one example, I provide a mechanism that allows developers
to archive the configuration
of their Haskell development environment and check it into a source management
system. The developer can check it out on a another system and if the
build process
invokes the recovery mechansim it will automatically rebuild the
environment on the
first run (reporting an error if the required tool chain is not
installed on the system).
Subsequent runs of the build process will merely check that nothing has been
disturbed and proceed straight to the main build process.
Maybe Nix provides such a mechanism -- I don't know. But all attempts
to discover
this and other mechanisms have failed and any hard information that I
come across suggests
that this is unlikely. (Hint: it is mostly concerned with the Haskell
*user* package DB;
I have just expanded on the 'archiving' part of the original
announcement by the way.)
It is a great shame as I like the Nix philsophy and I would like to
see the other distributions
adopt more of its functional philosophy.
But I am out of time. If you will excuse me I would rather wind up
this thread once you have replied
(if you would like to)
Chris
Andres Löh
Jun 16, 2012, 5:52:58 AM6/16/12
to Chris Dornan, haskel...@haskell.org
Hi Chris.
[Sorry if I'm slow responding, but I'm at a summer school right now
and have relatively little time to follow my email.]
> At issue is whether the JustHub Haskell distribution for Enterprise Linux
> and
> the hub hackage for sandboxing development projects and integrating multiple
> GHC
> tool chains is redundant because all of the functionality is covered by the
> Nix Haskell distribution, allowing as they do multiple Nix Haskell releases
> to
> be deployed simultaneously.]
Let me clarify this in advance: I'm *not* questioning the usefulness
of JustHub at all! It's great that you provide it. I was asking
whether integrating JustHub *into* Nix and/or NixOS would make sense
and would provide any benefit on top of the features already provided
by these systems. As I indicated, I'm not yet convinced of that. I
asked the question in order to learn more about JustHub. I do
completely understand that Nix is not for everyone and that JustHub
may have less dependencies that make it a very attractive choice for a
wide range of applications.
> All of the standard Haskell tools inter-operate cleanly and
> transparently with the sandboxes and operate in the normal way
> outside of them.
I guess this may be the main point. You're saying you can use the
standard tools to work with hubs and don't need to do anything
special, whereas in Nix(OS) you admittedly only get the full benefit
of the system if you're installing packages via Nix rather than via
Cabal.
As Peter has pointed out, you're usually working in Nix(OS) with
several profiles. Each of these profiles can contain an arbitrary set
of packages (not limited to Haskell or GHC). It's possible to switch
between profiles easily. It's possible to use different profiles for
development on different projects. Different profiles can contain
different versions of GHC as well as different sets or variants of
packages.
> Sandboxed environments (hubs) can be shared between work trees as well
> as being (re)named, annotated, replicated, swapped, archived, locked
> and removed. Proper package deletion with the option of garbage
> collecting orphaned code and documentation is also supported.
I'm not completely sure what each of these mean. Package removal is
certainly supported in Nix(OS), but again, admittedly, not via the
standard tools. You have to invoke nix-specific commands in order to
perform garbage collection.
> I have loaded GHC-7.4.1 platform and the GHC-7.0.4 into Nix and it installs
> all of the ghc drivers
> into a single bin directory in the user's profile. I am guessing that
> running `ghc` will generally
> get you the latest compiler you have installed (7.4.1 in my case); specific
> releases can be
> invoked with ghc-7.0.4, etc.
Installing the latest version into the main user profile is merely the
default functionality. There's absolutely no problem selecting older
versions or installing into separate profiles. If you look at the
files actually installed, you'll find that all files in a profile are
just links, and that each Haskell package in fact lives in isolation
in its own directory in the Nix store.
> This hardly covers all of the above functionality!
It might not. We're having this discussion in order to find out, I think :)
> Quite related to this (in my mind anyway) are the user-level facilities for
> managing the package
> databases that each work tree uses -- the problems that cabal-dev was
> created to solve. What I
> have done is to create a system that manages the environment each source
> work tree uses.
> If you are in a 2012.2.0.0-based project work tree then the ghc-driver will
> detect that and invoke
> the right tools. The 2012.2 platform uses cabal-instal-0.14 and that is what
> you will get when
> you invoke cabal in such a work tree.
You still have to say at some initial point what version you want to
use, I hope? Otherwise, I can't see how it could be detected.
> However in work trees based on earlier version of the compiler (e.g.,
> GHC-7.2.2), cabal-install-0.10.2
> will be used because cabal-install-0.14.0 doesn't interoperate very well
> with cabal-0.10 and earlier
> (see https://github.com/haskell/cabal/issues/932). Also in such a work tree
> you will get all
> of the tools that were shipped with the GHC-7.2.2 and all through issuing
> the usual command
> 'ghc', 'ghci', 'ghc-pkg', etc).
Independent of concrete bugs, who's making these decisions? Can I use
cabal-install-0.14.0 on projects working with older platforms if I
want to?
> Without some system to help the user invoke the right tools in the right
> context, having to invoke
> each version of the compiler explicitly can get awkward to use quite
> quickly.
This is not required in Nix(OS). You switch the profile and then get
the versions you have in your profile. The profile is not tied to
working dirs, you have to manually switch. I think both approaches
have their disadvantages in practice (i.e., either the user shell or
the working dir are "stateful").
> Think about installing a
> package into a 7.0.4-based work tree where 'ghc' runs version 7.4.1. Cabal
> will reach for 7.4.1 unless
> told otherwise. The only practical way to do this is to build a PATH where
> the right tools get run on
> the default commands ('ghc', 'ghc-pkg', etc),
Yes. This is what you get with Nix(OS).
> or equivalently use
> intelligent drivers that make sure
> the right tools get invoked (the method JustHub uses).
Ok.
> It is also sometimes helpful to be able to start from the minimal collection
> of packages that you get with
> compiler (sans platform packages) and build your collection from there. The
> JustHub system allows
> you to do this, even on installations that are working double time as
> Haskell Platform instantiations.
Not a problem in Nix(OS) either. Indeed, for each compiler version I
have standard "plain" and "platform" profiles installed on my machine,
with just the GHC-provided or just the platform packages. In addition,
I then have project-specific profiles. The packages, as far as they're
contained in several profiles, are installed only once and shared via
the Nix store.
> GHC+cabal do provide an awesome build system but the package management
> mechanisms aren't as
> easy to use as they could be. There is no proper mechanism for erasing
> packages for instance (arguably
> because it is meaningless -- reinforcing my point) and the mechanisms for
> managing package databases
> are inconsistent across the tools (differing between 'cabal' and
> 'ghc'/ghc-pkg') and not very friendly
> (requiring the setting up of environment variables and the use of special
> flags). I have also found it highly
> useful to be able to name, replicate, archive and share environments between
> different work trees
Right. That's why in Nix(OS) we currently don't try to actually patch
cabal-install or other tools to behave differently from normal. So
you're free to use for example cabal-dev on top of a NixOS profile,
but in order to benefit from NixOS fully, you should install Haskell
packages via Nix. We have tools that try to make it easy to add new
packages to the Nixpkgs collection semi-automatically, but admittedly,
that's not quite as simple as typing "cabal install".
> You may dismiss that as pointless or irrelevant but it _is_ a large part of
> what I am trying get right and it did
> feature prominently in the announcement.
Let me say again that I'm curious to learn the differences. Thanks for
taking the time to explain this to me, as I haven't had the time to
work with JustHub yet, and it certainly looks very interesting. I'm
*not* trying to dismiss JustHub as being useless. OTOH, there's
certainly overlap between the two systems. So if we're ever thinking
of integrating one into the other, I'd like to make sure that there
isn't too much redundancy.
> I think the Nix functional
> approach to distributions is definitely going in the right direction in
> giving user better control over which
> packages are installed but, unless I have missed something, I don't think it
> is so definitive that there isn't
> room for other developments.
I never said that.
> Finally a couple of gripes with Nix as a replacement for JustHub.
> [...]
I also never suggested that, at least not in general. If anything, I'd
say that people interested in JustHub might also be interested to look
at Nix(OS).
> Also I could not determine which releases of GHC you are supporting. It
> looks as the distribution is focused
> on the Haskell Platform, in which case only those releases of GHC will be
> available, when they get scheduled
> for inclusion in the platform.
NixOS is a community project that the moment, there's no official
definition of "support". In practice, we have GHC versions 6.10.4,
6.12.1, 6.12.2, 6.12.3, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.2.1, 7.2.2,
7.4.1, 7.4.2 and HEAD (snapshot). There's no restriction to platform
releases.
Cheers,
Andres
[Sorry if I'm slow responding, but I'm at a summer school right now
and have relatively little time to follow my email.]
> At issue is whether the JustHub Haskell distribution for Enterprise Linux
> and
> the hub hackage for sandboxing development projects and integrating multiple
> GHC
> tool chains is redundant because all of the functionality is covered by the
> Nix Haskell distribution, allowing as they do multiple Nix Haskell releases
> to
> be deployed simultaneously.]
of JustHub at all! It's great that you provide it. I was asking
whether integrating JustHub *into* Nix and/or NixOS would make sense
and would provide any benefit on top of the features already provided
by these systems. As I indicated, I'm not yet convinced of that. I
asked the question in order to learn more about JustHub. I do
completely understand that Nix is not for everyone and that JustHub
may have less dependencies that make it a very attractive choice for a
wide range of applications.
> All of the standard Haskell tools inter-operate cleanly and
> transparently with the sandboxes and operate in the normal way
> outside of them.
standard tools to work with hubs and don't need to do anything
special, whereas in Nix(OS) you admittedly only get the full benefit
of the system if you're installing packages via Nix rather than via
Cabal.
As Peter has pointed out, you're usually working in Nix(OS) with
several profiles. Each of these profiles can contain an arbitrary set
of packages (not limited to Haskell or GHC). It's possible to switch
between profiles easily. It's possible to use different profiles for
development on different projects. Different profiles can contain
different versions of GHC as well as different sets or variants of
packages.
> Sandboxed environments (hubs) can be shared between work trees as well
> as being (re)named, annotated, replicated, swapped, archived, locked
> and removed. Proper package deletion with the option of garbage
> collecting orphaned code and documentation is also supported.
certainly supported in Nix(OS), but again, admittedly, not via the
standard tools. You have to invoke nix-specific commands in order to
perform garbage collection.
> I have loaded GHC-7.4.1 platform and the GHC-7.0.4 into Nix and it installs
> all of the ghc drivers
> into a single bin directory in the user's profile. I am guessing that
> running `ghc` will generally
> get you the latest compiler you have installed (7.4.1 in my case); specific
> releases can be
> invoked with ghc-7.0.4, etc.
default functionality. There's absolutely no problem selecting older
versions or installing into separate profiles. If you look at the
files actually installed, you'll find that all files in a profile are
just links, and that each Haskell package in fact lives in isolation
in its own directory in the Nix store.
> This hardly covers all of the above functionality!
> Quite related to this (in my mind anyway) are the user-level facilities for
> managing the package
> databases that each work tree uses -- the problems that cabal-dev was
> created to solve. What I
> have done is to create a system that manages the environment each source
> work tree uses.
> If you are in a 2012.2.0.0-based project work tree then the ghc-driver will
> detect that and invoke
> the right tools. The 2012.2 platform uses cabal-instal-0.14 and that is what
> you will get when
> you invoke cabal in such a work tree.
use, I hope? Otherwise, I can't see how it could be detected.
> However in work trees based on earlier version of the compiler (e.g.,
> GHC-7.2.2), cabal-install-0.10.2
> will be used because cabal-install-0.14.0 doesn't interoperate very well
> with cabal-0.10 and earlier
> (see https://github.com/haskell/cabal/issues/932). Also in such a work tree
> you will get all
> of the tools that were shipped with the GHC-7.2.2 and all through issuing
> the usual command
> 'ghc', 'ghci', 'ghc-pkg', etc).
cabal-install-0.14.0 on projects working with older platforms if I
want to?
> Without some system to help the user invoke the right tools in the right
> context, having to invoke
> each version of the compiler explicitly can get awkward to use quite
> quickly.
the versions you have in your profile. The profile is not tied to
working dirs, you have to manually switch. I think both approaches
have their disadvantages in practice (i.e., either the user shell or
the working dir are "stateful").
> Think about installing a
> package into a 7.0.4-based work tree where 'ghc' runs version 7.4.1. Cabal
> will reach for 7.4.1 unless
> told otherwise. The only practical way to do this is to build a PATH where
> the right tools get run on
> the default commands ('ghc', 'ghc-pkg', etc),
> or equivalently use
> intelligent drivers that make sure
> the right tools get invoked (the method JustHub uses).
> It is also sometimes helpful to be able to start from the minimal collection
> of packages that you get with
> compiler (sans platform packages) and build your collection from there. The
> JustHub system allows
> you to do this, even on installations that are working double time as
> Haskell Platform instantiations.
have standard "plain" and "platform" profiles installed on my machine,
with just the GHC-provided or just the platform packages. In addition,
I then have project-specific profiles. The packages, as far as they're
contained in several profiles, are installed only once and shared via
the Nix store.
> GHC+cabal do provide an awesome build system but the package management
> mechanisms aren't as
> easy to use as they could be. There is no proper mechanism for erasing
> packages for instance (arguably
> because it is meaningless -- reinforcing my point) and the mechanisms for
> managing package databases
> are inconsistent across the tools (differing between 'cabal' and
> 'ghc'/ghc-pkg') and not very friendly
> (requiring the setting up of environment variables and the use of special
> flags). I have also found it highly
> useful to be able to name, replicate, archive and share environments between
> different work trees
cabal-install or other tools to behave differently from normal. So
you're free to use for example cabal-dev on top of a NixOS profile,
but in order to benefit from NixOS fully, you should install Haskell
packages via Nix. We have tools that try to make it easy to add new
packages to the Nixpkgs collection semi-automatically, but admittedly,
that's not quite as simple as typing "cabal install".
> You may dismiss that as pointless or irrelevant but it _is_ a large part of
> what I am trying get right and it did
> feature prominently in the announcement.
taking the time to explain this to me, as I haven't had the time to
work with JustHub yet, and it certainly looks very interesting. I'm
*not* trying to dismiss JustHub as being useless. OTOH, there's
certainly overlap between the two systems. So if we're ever thinking
of integrating one into the other, I'd like to make sure that there
isn't too much redundancy.
> I think the Nix functional
> approach to distributions is definitely going in the right direction in
> giving user better control over which
> packages are installed but, unless I have missed something, I don't think it
> is so definitive that there isn't
> room for other developments.
> Finally a couple of gripes with Nix as a replacement for JustHub.
I also never suggested that, at least not in general. If anything, I'd
say that people interested in JustHub might also be interested to look
at Nix(OS).
> Also I could not determine which releases of GHC you are supporting. It
> looks as the distribution is focused
> on the Haskell Platform, in which case only those releases of GHC will be
> available, when they get scheduled
> for inclusion in the platform.
definition of "support". In practice, we have GHC versions 6.10.4,
6.12.1, 6.12.2, 6.12.3, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.2.1, 7.2.2,
7.4.1, 7.4.2 and HEAD (snapshot). There's no restriction to platform
releases.
Cheers,
Andres
Chris Dornan
Jun 16, 2012, 3:21:33 PM6/16/12
to Andres Löh, haskel...@haskell.org
Hi Andres,
Thanks for your detailed reply -- it is much appreciated.
> Independent of concrete bugs, who's making these decisions? Can I use
> cabal-install-0.14.0 on projects working with older platforms if I
> want to?
Out of the box you get a set of tools that avoids known problems and
complies
with the particular platform. It is easy to override this in the
configuration
file. I expect to add commands to carry out that reconfiguration soon.
> Not a problem in Nix(OS) either. Indeed, for each compiler version I
> have standard "plain" and "platform" profiles installed on my machine,
Excellent!
> You still have to say at some initial point what version you want to
> use, I hope? Otherwise, I can't see how it could be detected.
Indeed. It can be done statically (by configuring the directory) or
dynamically (by setting an environment variable).
I think I am getting a feel for how Nix works. As I understand it Nix
provides the user with fine control of the combination of packages
that can be installed in a profile. A user can maintain many profiles
and switch between them.
(As I have been saying) I like it. Most of the issues I have been addressing
in the hub system are concerned with managing the Haskell user package
database. Each project needs to know where to find the tools and where to
find the global package database but they are generally static and come
pre-packaged in the configuration file. The real action in the Hub system
lies in managing the user package database.
As I see it the developer's project configuration belongs in the source code
repository. Once the developer has checked out the work tree the tools
should take care of the rest. (And the tools behave as normal in the
absence of such configuration.) Everything I have been trying to do
has been geared towards this and helping the developer to manage
the development environment.
Cheers,
Chris
Thanks for your detailed reply -- it is much appreciated.
> Independent of concrete bugs, who's making these decisions? Can I use
> cabal-install-0.14.0 on projects working with older platforms if I
> want to?
complies
with the particular platform. It is easy to override this in the
configuration
file. I expect to add commands to carry out that reconfiguration soon.
> Not a problem in Nix(OS) either. Indeed, for each compiler version I
> have standard "plain" and "platform" profiles installed on my machine,
> You still have to say at some initial point what version you want to
> use, I hope? Otherwise, I can't see how it could be detected.
dynamically (by setting an environment variable).
I think I am getting a feel for how Nix works. As I understand it Nix
provides the user with fine control of the combination of packages
that can be installed in a profile. A user can maintain many profiles
and switch between them.
(As I have been saying) I like it. Most of the issues I have been addressing
in the hub system are concerned with managing the Haskell user package
database. Each project needs to know where to find the tools and where to
find the global package database but they are generally static and come
pre-packaged in the configuration file. The real action in the Hub system
lies in managing the user package database.
As I see it the developer's project configuration belongs in the source code
repository. Once the developer has checked out the work tree the tools
should take care of the rest. (And the tools behave as normal in the
absence of such configuration.) Everything I have been trying to do
has been geared towards this and helping the developer to manage
the development environment.
Cheers,
Chris
Peter Simons
Jun 17, 2012, 7:34:29 AM6/17/12
to haskel...@haskell.org
Hi Chris,
>> How much time, approximately, did you spend working with Nix?
actually, no. I don't know that, which is why I asked. I find it hard to
get an answer from you, though. It seems strange that you keep such
trivial information to yourself like some super personal secret. The
point of this discussion is to compare the respective properties of Nix
and Hub. In that context, it seems natural that I might be curious how
much actual working experience you have with Nix.
> JustHub [and Nix] have some similarities -- mostly around the idea of
a little bit more specific? How exactly do Nix and Hub differ in the way
they install multiple tool-chains?
> I also know that I have been adding things that a generic package
> manager is most unlikely to be covering [...].
What you mean is: you really don't know, but you are speculating.
> To take just one example, I provide a mechanism that allows
> developers to archive the configuration of their Haskell development
> environment and check it into a source management system. The
> developer can check it out on a another system and if the build
> process invokes the recovery mechanism it will automatically rebuild
> the environment on the first run [...].
Yes, is Nix we solve that problem as follows. Configurations are lazily
evaluated functions. The function that builds Hub, for example, looks
like this:
| { cabal, fgl, filepath, hexpat, regexCompat, utf8String }:
|
| cabal.mkDerivation (self: {
| pname = "hub";
| version = "1.1.0";
| sha256 = "0vwn1v32l1pm38qqms9ydjl650ryic37xbl35md7k6v8vim2q8k3";
| isLibrary = false;
| isExecutable = true;
| buildDepends = [ fgl filepath hexpat regexCompat utf8String ];
| meta = {
| homepage = "https://justhub.org";
| description = "For multiplexing GHC installations and providing development sandboxes";
| license = self.stdenv.lib.licenses.bsd3;
| platforms = self.ghc.meta.platforms;
| };
| })
When Nix runs that build, it's executed in a temporary environment that
contains exactly those package that have been declared as build inputs,
but nothing else. Since all built-time dependencies of this package are
arguments of the function, it's possible to instantiate that build with
any version of GHC, Cabal, fgl, filepath, etc. If I pass GHC 6.12.3, Hub
will be built with GHC 6.12.3. If I pass GHC 7.4.2, Hub will be built
with GHC 7.4.2 instead.
Now, in my home directory there is a file ~/.nixpkgs/config.nix that
works like the 'main' function in a Haskell program insofar as that it
ties all those individual functions together into an user configuration:
| let
| haskellEnv = pkgs: pkgs.ghcWithPackages (self: with pkgs; [
| # Haskell Platform
| haskellPlatform
| # other packages
| cmdlib dimensional funcmp hackageDb hledger hledgerLib hlint hoogle
| HStringTemplate monadPar pandoc smallcheck tar uulib permutation
| criterion graphviz async
| ]);
| in
| {
| packageOverrides = pkgs:
| {
| ghc704Env = haskellEnv pkgs.haskellPackages_ghc704;
| ghc741Env = haskellEnv pkgs.haskellPackages_ghc741;
| ghc742Env = haskellEnv pkgs.haskellPackages_ghc742;
| };
| }
I can copy that file to every other machine, regardless of whether it's
a Linux host, a Mac, or a BSD Unix, and run
nix-env -iA ghc704Env
to have Nix build my GHC 7.0.4 development environment with exactly
those extra libraries that I configured.
How would I do something like that in Hub?
> Maybe Nix provides such a mechanism -- I don't know.
It does. :-)
Take care,
Peter
>> How much time, approximately, did you spend working with Nix?
>> 1 hour? 10 hours? 10 days? 10 months?
>
> You know that it is not 10 months.
>
actually, no. I don't know that, which is why I asked. I find it hard to
get an answer from you, though. It seems strange that you keep such
trivial information to yourself like some super personal secret. The
point of this discussion is to compare the respective properties of Nix
and Hub. In that context, it seems natural that I might be curious how
much actual working experience you have with Nix.
> JustHub [and Nix] have some similarities -- mostly around the idea of
> allowing multiple tool chains to co-exist; the way they go about it
> is very different.
I'm not sure what differences you are referring to. Could you please be
> is very different.
a little bit more specific? How exactly do Nix and Hub differ in the way
they install multiple tool-chains?
> I also know that I have been adding things that a generic package
What you mean is: you really don't know, but you are speculating.
> To take just one example, I provide a mechanism that allows
> developers to archive the configuration of their Haskell development
> environment and check it into a source management system. The
> developer can check it out on a another system and if the build
> the environment on the first run [...].
Yes, is Nix we solve that problem as follows. Configurations are lazily
evaluated functions. The function that builds Hub, for example, looks
like this:
| { cabal, fgl, filepath, hexpat, regexCompat, utf8String }:
|
| cabal.mkDerivation (self: {
| pname = "hub";
| version = "1.1.0";
| sha256 = "0vwn1v32l1pm38qqms9ydjl650ryic37xbl35md7k6v8vim2q8k3";
| isLibrary = false;
| isExecutable = true;
| buildDepends = [ fgl filepath hexpat regexCompat utf8String ];
| meta = {
| homepage = "https://justhub.org";
| description = "For multiplexing GHC installations and providing development sandboxes";
| license = self.stdenv.lib.licenses.bsd3;
| platforms = self.ghc.meta.platforms;
| };
| })
When Nix runs that build, it's executed in a temporary environment that
contains exactly those package that have been declared as build inputs,
but nothing else. Since all built-time dependencies of this package are
arguments of the function, it's possible to instantiate that build with
any version of GHC, Cabal, fgl, filepath, etc. If I pass GHC 6.12.3, Hub
will be built with GHC 6.12.3. If I pass GHC 7.4.2, Hub will be built
with GHC 7.4.2 instead.
Now, in my home directory there is a file ~/.nixpkgs/config.nix that
works like the 'main' function in a Haskell program insofar as that it
ties all those individual functions together into an user configuration:
| let
| haskellEnv = pkgs: pkgs.ghcWithPackages (self: with pkgs; [
| # Haskell Platform
| haskellPlatform
| # other packages
| cmdlib dimensional funcmp hackageDb hledger hledgerLib hlint hoogle
| HStringTemplate monadPar pandoc smallcheck tar uulib permutation
| criterion graphviz async
| ]);
| in
| {
| packageOverrides = pkgs:
| {
| ghc704Env = haskellEnv pkgs.haskellPackages_ghc704;
| ghc741Env = haskellEnv pkgs.haskellPackages_ghc741;
| ghc742Env = haskellEnv pkgs.haskellPackages_ghc742;
| };
| }
I can copy that file to every other machine, regardless of whether it's
a Linux host, a Mac, or a BSD Unix, and run
nix-env -iA ghc704Env
to have Nix build my GHC 7.0.4 development environment with exactly
those extra libraries that I configured.
How would I do something like that in Hub?
> Maybe Nix provides such a mechanism -- I don't know.
Take care,
Peter
Chris Dornan
Jun 17, 2012, 3:43:16 PM6/17/12
to Peter Simons, haskel...@haskell.org
> How would I do something like that [save and restore a Hakell project configuration] in Hub?
Once I have an environment I am happy with, I save its configuration
(here the hub is named 'project'):
hub save project >project.har
I would check this file into the source repository and at the start of
the build process
(it could be in a script or makefile) I would load it thus:
hub load project <project.har
While the build environment is stable this will just check that
the environment matches the configuration and immediately continue
with the normal build process.
But when I check out and build the source tree on another
system it will locate the tools specified in the configuration
file and rebuild the user package database, complaining if it
can't locate the right tools.
There are more examples at http://justhub.org/overview
Chris
Once I have an environment I am happy with, I save its configuration
(here the hub is named 'project'):
hub save project >project.har
I would check this file into the source repository and at the start of
the build process
(it could be in a script or makefile) I would load it thus:
hub load project <project.har
While the build environment is stable this will just check that
the environment matches the configuration and immediately continue
with the normal build process.
But when I check out and build the source tree on another
system it will locate the tools specified in the configuration
file and rebuild the user package database, complaining if it
can't locate the right tools.
There are more examples at http://justhub.org/overview
Chris
Peter Simons
Jun 18, 2012, 1:24:54 PM6/18/12
to haskel...@haskell.org
Hi Chris,
> hub save project >project.har
I am curious to see what this file looks like. Could you please post a
short example of one?
Take care,
Peter
> hub save project >project.har
I am curious to see what this file looks like. Could you please post a
short example of one?
Take care,
Peter
Chris Dornan
Jun 18, 2012, 4:42:46 PM6/18/12
to Peter Simons, haskel...@haskell.org
Hi Peter,
> > hub save project >project.har
>
> I am curious to see what this file looks like. Could you please post a
short example of one?
There is a worked out example at the bottom of the overview up on the web
site:
http://justhub.org/overview
The configurations are quite simple, just listing the global package and the
list of packages in the user
database. When I provide command sets for refining the versions of the tools
used with each hub (esp.
cabal-install, only possible by hacking the configuration file at the
moment) I will add this information
to the hub configuration archives.
Chris
> > hub save project >project.har
>
> I am curious to see what this file looks like. Could you please post a
short example of one?
site:
http://justhub.org/overview
The configurations are quite simple, just listing the global package and the
list of packages in the user
database. When I provide command sets for refining the versions of the tools
used with each hub (esp.
cabal-install, only possible by hacking the configuration file at the
moment) I will add this information
to the hub configuration archives.
Chris
Peter Simons
Jun 18, 2012, 4:59:22 PM6/18/12
to haskel...@haskell.org
Hi Chris,
> There is a worked out example at the bottom of the overview up on the
> web site: http://justhub.org/overview
thank you for the pointer, I think I found it:
^=7.4.1
List-0.4.2
fgl-5.4.2.4
hexpat-0.20.1
mtl-2.1.1
regex-base-0.93.2
regex-compat-0.95.1
regex-posix-0.95.2
text-0.11.2.1
transformers-0.3.0.0
utf8-string-0.3.7
Very nice, this looks quite straightforward. I wonder about two things:
- Is it possible to pass configure-time flags to those libraries? For
example, I would like to build "haskeline" with "-fterminfo". Can Hub
do this?
- How do you handle packages that depend on system libraries? "hsdns",
for example, requires the adns library to build. Does Hub know about
this?
Take care,
Peter
> There is a worked out example at the bottom of the overview up on the
> web site: http://justhub.org/overview
^=7.4.1
List-0.4.2
fgl-5.4.2.4
hexpat-0.20.1
mtl-2.1.1
regex-base-0.93.2
regex-compat-0.95.1
regex-posix-0.95.2
text-0.11.2.1
transformers-0.3.0.0
utf8-string-0.3.7
Very nice, this looks quite straightforward. I wonder about two things:
- Is it possible to pass configure-time flags to those libraries? For
example, I would like to build "haskeline" with "-fterminfo". Can Hub
do this?
- How do you handle packages that depend on system libraries? "hsdns",
for example, requires the adns library to build. Does Hub know about
this?
Take care,
Peter
Chris Dornan
Jun 20, 2012, 3:46:48 PM6/20/12
to Peter Simons, haskel...@haskell.org
[Sorry for the delay -- I missed this reply until prompted.]
> Very nice, this looks quite straightforward. I wonder about two things:
> - Is it possible to pass configure-time flags to those libraries? For
> example, I would like to build "haskeline" with "-fterminfo". Can
Hub
> do this?
> - How do you handle packages that depend on system libraries? "hsdns",
> for example, requires the adns library to build. Does Hub know about
> this?
Well observed! There is currently no provision for getting special arguments
passed
to cabal install when rebuilding the packages -- a weakness that should be
addressed.
Chris
> Very nice, this looks quite straightforward. I wonder about two things:
> - Is it possible to pass configure-time flags to those libraries? For
> example, I would like to build "haskeline" with "-fterminfo". Can
Hub
> do this?
> - How do you handle packages that depend on system libraries? "hsdns",
> for example, requires the adns library to build. Does Hub know about
> this?
passed
to cabal install when rebuilding the packages -- a weakness that should be
addressed.
Chris
Peter Simons
Jun 20, 2012, 3:55:37 PM6/20/12
to haskel...@haskell.org
Hi Chris,
I'm also wondering about this issue:
>> - How do you handle packages that depend on system libraries? "hsdns",
>> for example, requires the adns library to build. Does Hub know about
>> this?
Does Hub know about system-level libraries that Haskell packages need to
build, like Gtk, ADNS, Avahi, etc.?
Take care,
Peter
I'm also wondering about this issue:
>> - How do you handle packages that depend on system libraries? "hsdns",
>> for example, requires the adns library to build. Does Hub know about
>> this?
build, like Gtk, ADNS, Avahi, etc.?
Take care,
Peter
Chris Dornan
Jun 21, 2012, 8:58:31 AM6/21/12
to Peter Simons, haskel...@haskell.org
> Does Hub know about system-level libraries that Haskell packages need
> to build, like Gtk, ADNS, Avahi, etc.?
As is the case for cabal-install, ensuring the right system libraries are
> to build, like Gtk, ADNS, Avahi, etc.?
installed is outside its scope.
Chris
Reply all
Reply to author
Forward
0 new messages