Quantcast

capri cabal-dev virtualenv cab

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

capri cabal-dev virtualenv cab

Rustom Mody
Does anyone give me a little comparison of these?

What would all my requirements be? Not sure... these seem important for me

1. Need to sandbox not just haskell-projects but ghc (different
compilations/versions) itself
2. Stability of the (sandboxing) tool
3. Correcting the deficiencies of cabal (eg inability to uninstall,
quarrels between cabal and apt etc)

OS: Debian/testing
System haskell: 7.0.4

My question on beginners for a little more context:
http://www.haskell.org/pipermail/beginners/2011-November/008943.html

capri: http://www.haskell.org/haskellwiki/Capri
virtualenv: https://github.com/Paczesiowa/virthualenv
cabal-dev:
http://corp.galois.com/blog/2010/12/20/cabal-dev-sandboxed-development-builds-for-haskell.html
cab: http://www.mew.org/~kazu/proj/cab/en/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: capri cabal-dev virtualenv cab

paul r-2
Hey,

Rustom> Does anyone give me a little comparison of these? What would all
Rustom> my requirements be? Not sure... these seem important for me

Rustom> 1. Need to sandbox not just haskell-projects but ghc (different
Rustom> compilations/versions) itself 2. Stability of the (sandboxing)
Rustom> tool 3. Correcting the deficiencies of cabal (eg inability to
Rustom> uninstall, quarrels between cabal and apt etc)

I'll also appreciate users recommandations here. In spite of some decent
experience with Haskell and administration, I keep falling regulary into
various traps, particulary when in comes to managing cabal with multiple
GHCs. Lately, 2 days after a fresh GHC install, a cabal install failed
because of version mismatch in a package between system and user
database, and I was forced to clear up the whole thing. I'd much prefer
to spend my time hacking my haskell software ;)

At the moment, my strategy to swap GHC is purely based on the PATH
environment, and that works well if you don't forget to set this env
before hacking a project. My strategy for cabal is a bit more
convoluted, because I had *so many* troubles with multiple databases
(AKA system db and user db), I decided that everything would go in the
'system' one, which is actually just in my user-local GHC install, for
which my user obviously have required permissions. Things seem to work
a bit better that way, I guess because cabal has easier time handling
dependencies.

So far I avoided the project-local database strategy because my system
does not have much computational power, and I'm bored of waiting for
ubiquitous packages to compile in all my folders. Arguably, that would
be the only safe and simple way to avoid clashes, but I'd appreciate
some shared cache to avoid recompiling the same stuff multiple times. Is
there some wrappers that can take care of that ?


Cheers,

--
  Paul

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: capri cabal-dev virtualenv cab

Marc Weber
In reply to this post by Rustom Mody
nixos.org (eg hack-nix) addresses those issues (but may introduce some
more less important ones).

You can setup multiple project specific build environments easily.

If you're interested contact me on irc.freenode.net or by mail.
(nick MarcWeber)

I don't know the other solutions so I can't comment on them.

Marc Weber

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: capri cabal-dev virtualenv cab

Rogan Creswick
In reply to this post by paul r-2
On Tue, Nov 8, 2011 at 1:43 AM, Paul R <[hidden email]> wrote:
>
> At the moment, my strategy to swap GHC is purely based on the PATH
> environment, and that works well if you don't forget to set this env
> before hacking a project.

This is the best solution I'm currently aware of, but there are ways
we could improve on this (involving new sandboxing tools; similar to
NixOS).

> My strategy for cabal is a bit more
> convoluted, because I had *so many* troubles with multiple databases
> (AKA system db and user db), I decided that everything would go in the
> 'system' one, which is actually just in my user-local GHC install, for
> which my user obviously have required permissions.

I strongly caution against doing this.  My advice is: (explanations below)

 1) /never/ install anything into your system db:
 2) /never/ explicitly install packages that come with ghc (the
packages that are in your system db)
 3) don't rely on your user package db for development -- it's a
convenient place to put things you want to use in ghci, and it's the
simplest thing to use when installing Haskell applications (such as
cabal, cabal-dev, cab, etc...)
 4) use cabal-dev for all development.

Explanations:

(1): Installing to your system package db will prevent you from
sandboxing builds in the context of the Haskell package system.  You
can restrict to individual ghcs, since each ghc has it's own system
db, but you can't prevent your installed package versions from causing
your builds to behave differently than my builds -- as a result, you
may not realize that your package version bounds are broken, for
example.  You'll also not notice when new versions of dependencies
cause your build to break, and you may experience failures when
building other packages because you have a different set of installed
dependencies than the developer expected.

(1 & 2): These things, together, will prevent you from having version
conflicts between the system and user dbs.  Furthermore, cabal-dev
doesn't hide the system db (the tools cabal-dev uses don't expose an
api that enables that in the way that the user db can be hidden, and
the libraries installed in the system db by ghc usually can't be
upgraded/reinstalled without upgrading ghc anyway).

(3) It's impractical to keep your user db clean enough to accomplish
the same objectives of sandboxed builds -- you /can/ do it, but I
don't think it's worth the effort when other tools exist to help
(cabal-dev being my current hammer, capri should also do it, but I
haven't personally had success with capri).

(4) I'm sorry that cabal-dev adds computational overhead -- this
generally isn't an issue when compared to the long-term issues that
come up as a result of dependency resolution /without/ a sandbox, but
I realize that there are situations where cabal-dev can cause build
times to take significantly longer.  Ideas / suggestions / patches /
etc. are happily considered :)

--Rogan

> Things seem to work
> a bit better that way, I guess because cabal has easier time handling
> dependencies.
>
> So far I avoided the project-local database strategy because my system
> does not have much computational power, and I'm bored of waiting for
> ubiquitous packages to compile in all my folders. Arguably, that would
> be the only safe and simple way to avoid clashes, but I'd appreciate
> some shared cache to avoid recompiling the same stuff multiple times. Is
> there some wrappers that can take care of that ?
>
>
> Cheers,
>
> --
>  Paul
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: capri cabal-dev virtualenv cab

Rogan Creswick
In reply to this post by Rustom Mody
On Mon, Nov 7, 2011 at 11:40 PM, Rustom Mody <[hidden email]> wrote:
> Does anyone give me a little comparison of these?

capri & cabal-dev:

Capri and cabal-dev both sandbox Haskell builds by restricting the set
of packages that cabal can see -- I haven't had much luck with capri
personally, and it appears to take a bit more doing to get a project
instantiated, but it does seem to restrict access to the system
package db, which cabal-dev does not do.  It doesn't look like capri
is under active development (only one release, roughly 18 months ago).

cabal-dev was created and is primarily maintained by Galois (I'm one
of the maintainers), and it's used extensively for day-to-day
development.  cabal-dev works by wrapping invocations of cabal with
the necessary configuration files and command line arguments to
restrict cabal's access to package databases to the system package db
and a per-project db.  In practice, this solves the vast majority of
version conflict issues, and it also allows you to confidently state
that your software will build with the software currently on Hackage.
However, it does /not/ provide any facilities for restricting or
switching the versions of ghc, and it also doesn't sandbox any other
external build tools (such as alex / happy).  That's not necessarily
out of scope, but we haven't needed it enough yet to implement.

virtualenv:

I'm not familiar with virtualenv, but from skimming the site, it looks
like it does something very similar to cabal-dev, but focused on
python.  I'm not sure if it can be used with other languages /
arbitrary tools or not.

cab:

Others know cab much better than I do, but I'll take a shot.  I think
cab primarily provides a set of higher-level commands for managing a
ghc package database.  Amongst other things, it will show the complete
dependency tree for a package that is installed, and I think it wraps
'ghc-pkg unregister' more nicely, so you can unregister a package and
the packages that depend on it with one command.

It also wraps cabal-dev, I think, but I haven't used that bit, so I
don't know if it covers all the cabal-dev functionality yet.

--Rogan


>
> What would all my requirements be? Not sure... these seem important for me
>
> 1. Need to sandbox not just haskell-projects but ghc (different
> compilations/versions) itself
> 2. Stability of the (sandboxing) tool
> 3. Correcting the deficiencies of cabal (eg inability to uninstall,
> quarrels between cabal and apt etc)
>
> OS: Debian/testing
> System haskell: 7.0.4
>
> My question on beginners for a little more context:
> http://www.haskell.org/pipermail/beginners/2011-November/008943.html
>
> capri: http://www.haskell.org/haskellwiki/Capri
> virtualenv: https://github.com/Paczesiowa/virthualenv
> cabal-dev:
> http://corp.galois.com/blog/2010/12/20/cabal-dev-sandboxed-development-builds-for-haskell.html
> cab: http://www.mew.org/~kazu/proj/cab/en/
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: capri cabal-dev virtualenv cab

Brent Yorgey-2
On Tue, Nov 08, 2011 at 10:04:20AM -0800, Rogan Creswick wrote:
> On Mon, Nov 7, 2011 at 11:40 PM, Rustom Mody <[hidden email]> wrote:
> > Does anyone give me a little comparison of these?
>
> virtualenv:
>
> I'm not familiar with virtualenv, but from skimming the site, it looks
> like it does something very similar to cabal-dev, but focused on
> python.  I'm not sure if it can be used with other languages /
> arbitrary tools or not.

I'm guessing the OP was actually referring to 'virthualenv', which was
recently released and works with Haskell (but is similar to virtualenv
for python).  It seems that virthualenv lets you set up independent
"environments" including sandboxed builds and custom versions of GHC,
etc., and switch between them.

-Brent

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: capri cabal-dev virtualenv cab

Rogan Creswick
On Tue, Nov 8, 2011 at 10:57 AM, Brent Yorgey <[hidden email]> wrote:
>
> I'm guessing the OP was actually referring to 'virthualenv', which was
> recently released and works with Haskell (but is similar to virtualenv
> for python).  It seems that virthualenv lets you set up independent
> "environments" including sandboxed builds and custom versions of GHC,
> etc., and switch between them.

Ah!  Thanks, I wasn't aware of virthualenv.

So far, it looks cool.  I have a bit of a knee-jerk reaction to the
statefull approach it takes (heavily tweaking your active shell
environment to do the sandboxing), but it does do things that
cabal-dev doesn't.

Playing with it more now.

--Rogan

>
> -Brent
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Loading...