Ahh, I think network is a pain to build on Windows. I don't as a rule do
any haskell on windows because of the headaches of msys / mingw.
As to cabal-dev:
I don't think I even know what the paragraph means either. The short of it
is this:
You have packages that are globally registered with ghc, and packages that
are registered on a per user basis. When you call cabal-dev install foo it
makes a build dir called cabal-dev (you can change that) and builds foo in
there and installs + registers and deps that weren't in the global or user
database in there.
*phew*
hsenv: I forget that this is called virthualenv on hackage. It also allows
for sandboxing. Cabal-dev is probably easiest to start with.
You might want to read this:
http://www.reddit.com/r/haskell/comments/f3ykj/psa_use_cabaldev_to_solve_dep...
On Aug 16, 2012 2:21 PM, "Gregory Guthrie"
Thanks for the advice and pointers, I will try to make this transition, but it looks like it is not so simple.
Trying to bootstrap into cabal-dev seems to require some external installations as well;
>>cabal install cabal-dev --force-reinstalls ... Configuring network-2.3.0.14... cabal: The package has a './configure' script. This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. cabal: Error: some packages failed to install: HTTP-4000.2.3 depends on network-2.3.0.14 which failed to install. cabal-dev-0.9.1 depends on network-2.3.0.14 which failed to install. network-2.3.0.14 failed during the configure step. The exception was: ExitFailure 1
I do have MinGW+MSYS installed, might be a PATH issue, I'll check further.
I don't understand the details of Haskell package management, and the implications of this description of cabal-dev:
For installed packages, the sandboxing means that packages are not registered into the user or global ghc package database. The global package db is used, so it is recommended that the global package db is only used for the ghc core libraries. This approach conflicts with using distribution packages for non-core libraries, because they are installed into the global db.
It seems odd to me to say that "they are not registered.." into either database, and then say the global package db is used. Is there some distinction here between a "global ghc package db" & a "global package db"?.
Cabal install hsenv shows "no such package", and I'm not sure why using it with installs would be good.
Already removing shadowing packages is breaking things, so more cleanup will also be needed for that.
I am trying to convert some SML classes and labs for my students to Haskell, and all of this overhead is certainly something that I couldn't wish on them! Perhaps if I have them all start with cabal-dev none of this would happen?
-------------------------------------------
Please see this:
http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal- is-not-a-package-manager/
thanks Benjamin, for the cabal-dev, hsenv tip though.
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners