Re: [Haskell-cafe] capri cabal-dev virtualenv cab
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] capri cabal-dev virtualenv cab
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] capri cabal-dev virtualenv cab
On Tue, Nov 8, 2011 at 1:43 AM, Paul R paul.r...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] capri cabal-dev virtualenv cab
On Mon, Nov 7, 2011 at 11:40 PM, Rustom Mody rustompm...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] capri cabal-dev virtualenv cab
On Tue, Nov 08, 2011 at 10:04:20AM -0800, Rogan Creswick wrote: On Mon, Nov 7, 2011 at 11:40 PM, Rustom Mody rustompm...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] capri cabal-dev virtualenv cab
On Tue, Nov 8, 2011 at 10:57 AM, Brent Yorgey byor...@seas.upenn.edu 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] capri cabal-dev virtualenv cab
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
