paczesiowa/virthualenv

Virtual Haskell Environment builder

virthualenv's Issues

global cache of installed virthualenvs

create a file ~/.virthualenvs that will contain dict name -> path (maping virthualenv_name to its path)
create a shell script virthualenv-activate, that will take a name and activate it

add exception wrappers

when exception is thrown from down the call stack (like from runProcess) it's message is useless to the user (process failed with status 127 doesn't tell anything about missing ghc-pkg). add wrappers that will catch an exception, modify its message to be more meaningful to the user and throw it again

Not compiling in GHC-7.6

automatically source when moving into the directory

overriding cd seems fraught with peril. Perhaps you can just add the below to the documentation

function precmd() {
  if [[ -z $VIRTHUALENV_NAME ]]; then
    if [[ -e .virthualenv/bin/activate ]]; then
      source .virthualenv/bin/activate
    fi  
  fi
PROMPT="...$VIRTHUALENV_NAME..."
}

implement skip-sanity-check option

use tar library instead of calling system's tar

write proper .cabal file

use exceptions for everything that could fail

add option to use something else (e.g. gmake) instead of make

freebsd has GNU make available as gmake, so installing ghc from tarball fails with regular (posix?) make

GHC_PACKAGE_PATH failure with Haskell platform 2012-04

When using the latest Haskell platform and cabal 1.16.0.2, virthualenv fails on cabal commands e.g.

$ cabal install --only-dependencies --dry-run
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with
Cabal. Use the flag --package-db to specify a package database (it can be used
multiple times).

unset GHC_PACKAGE_PATH at the top of the cabal skeleton seems to fix it for me.

rode:haskell/src/virthualenv: git diff skeletons/cabal 18:08:32
diff --git a/skeletons/cabal b/skeletons/cabal
index 6319ec5..a7a7b12 100755
--- a/skeletons/cabal
+++ b/skeletons/cabal
@@ -1,5 +1,7 @@
#!/bin/sh

+unset GHC_PACKAGE_PATH
+
PATH_ELEMS="$(echo ${PATH} | tr -s ':' '\n')"

ORIG_CABAL_BINARY=""

log more things

fix logging messages indentations

check if .virthualenv dir already exists

use something fancier than ./tmp as temp dir

failure parsing depends field with package in user and global databases

When I had Cabal-1.12.0 in both my global and user databases, running virthualenv would fail.

Removing my user Cabal-1.12.0 fixed the problem, but was a dependency on the yesod I had built...

I don't know enough to say that having the same version of a package in my global and user databases isn't nonsensical, so maybe this is more an issue with me than with virthualenv -- and if so, then it might be beneficial (for clueless people like me :) to include a different error message.

Last bit of my virthualenv.log file (with the dependency strings) reformatted.

          ...
          Executing: ghc-pkg field Cabal-1.12.0 depends
            using inherited variable environment
            Process exited successfully
            Process output:
              depends: array-0.3.0.3-ea09841aaf8e340f109e7ae88f466cb2
                       base-4.4.1.0-1f81e4e7baf87af8ebbcf52b7bec2254
                       containers-0.4.1.0-f1a01354b46f586a2ae9c4625be9a212
                       directory-1.1.0.1-cbdf38734bd8fecb3519f4f9562ab1e4
                       filepath-1.2.0.1-16b7a7902f5c6a9398c10b6f4692a21f
                       old-time-1.0.0.7-7c5cbdbeec52c74fcdf7a52f1a3a00d2
                       pretty-1.1.0.0-ea03881a32f128dc4031082859a896d9
                       process-1.1.0.0-ded94950078eefc365bc43476bd795b0
                       unix-2.5.0.0-f4492dece9dbc86208534cb0c3e40076
              depends: array-0.3.0.3-ea09841aaf8e340f109e7ae88f466cb2
                       base-4.4.1.0-1f81e4e7baf87af8ebbcf52b7bec2254
                       containers-0.4.1.0-f1a01354b46f586a2ae9c4625be9a212
                       directory-1.1.0.1-cbdf38734bd8fecb3519f4f9562ab1e4
                       filepath-1.2.0.1-16b7a7902f5c6a9398c10b6f4692a21f
                       old-time-1.0.0.7-7c5cbdbeec52c74fcdf7a52f1a3a00d2
                       pretty-1.1.0.0-ea03881a32f128dc4031082859a896d9
                       process-1.1.0.0-ded94950078eefc365bc43476bd795b0
                       unix-2.5.0.0-f4492dece9dbc86208534cb0c3e40076
            Process error output:
        Found dependency strings:
           array-0.3.0.3-ea09841aaf8e340f109e7ae88f466cb2
           base-4.4.1.0-1f81e4e7baf87af8ebbcf52b7bec2254
           containers-0.4.1.0-f1a01354b46f586a2ae9c4625be9a212
           directory-1.1.0.1-cbdf38734bd8fecb3519f4f9562ab1e4
           filepath-1.2.0.1-16b7a7902f5c6a9398c10b6f4692a21f
           old-time-1.0.0.7-7c5cbdbeec52c74fcdf7a52f1a3a00d2
           pretty-1.1.0.0-ea03881a32f128dc4031082859a896d9
           process-1.1.0.0-ded94950078eefc365bc43476bd795b0
           unix-2.5.0.0-f4492dece9dbc86208534cb0c3e40076
           depends:
           array-0.3.0.3-ea09841aaf8e340f109e7ae88f466cb2
           base-4.4.1.0-1f81e4e7baf87af8ebbcf52b7bec2254
           containers-0.4.1.0-f1a01354b46f586a2ae9c4625be9a212
           directory-1.1.0.1-cbdf38734bd8fecb3519f4f9562ab1e4
           filepath-1.2.0.1-16b7a7902f5c6a9398c10b6f4692a21f
           old-time-1.0.0.7-7c5cbdbeec52c74fcdf7a52f1a3a00d2
           pretty-1.1.0.0-ea03881a32f128dc4031082859a896d9
           process-1.1.0.0-ded94950078eefc365bc43476bd795b0
           unix-2.5.0.0-f4492dece9dbc86208534cb0c3e40076

Couldn't parse package identifier depends:

add --version argument

check that required binaries exist (cabal, ghc-pkg)

if virthualenv exited successfully, write the log anyway

GHC 7.4.1 incompatibility

Won't build; when I just tweak the versioned dependencies, won't run.
Details on request, but I figure you'd just knock it out easily.

log every message to a log file

Docs for bootstrapping an environment using virthualenv

It would be great if usage instructions included installation instructions.

A common use of virthualenv would be to deploy some Haskell software somewhere, which includes setting up a Haskell environment on the target machine (e.g. web deployment), which might be shared hosting. What would be the best bootstrap approach in this situation? To install virthualenv I presumably need cabal-install first, and will also need cabal-install inside my virthualenv in order to install my actual software?

Thanks!

fix getting ghc pkg db from ghc-pkg output

newer versions don't put trailing color at the end of the line. it works by coincidence (both dropping it and keeping it), because the colon is always at the end of GHC_PACKAGE_PATH variable, and it's a valid separator (and looks like valid terminator), but it could fail when the user has a ~/.ghc/(..) for that version of GHC (because when using terminator in GHC_PACKAGE_PATH ghc tries to use global and user db)

MonadIO instance for MyMonad should catch IO exceptions

ExitFailure 11 with GHC 7.4

Trying to build from source:

virthualenv (master) $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1

Backtrace:

virthualenv (master) $ cabal install
Resolving dependencies...
Configuring virthualenv-0.2.1...
Building virthualenv-0.2.1...
Preprocessing executable 'virthualenv' for virthualenv-0.2.1...
[ 1 of 13] Compiling Util.Cabal       ( src/Util/Cabal.hs, dist/build/virthualenv/virthualenv-tmp/Util/Cabal.o )
[ 2 of 13] Compiling Skeletons        ( src/Skeletons.hs, dist/build/virthualenv/virthualenv-tmp/Skeletons.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package split-0.1.4.2 ... linking ... done.
Loading package safe-0.3.3 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package filepath-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package old-time-1.1.0.0 ... linking ... done.
Loading package unix-2.5.1.0 ... linking ... done.
Loading package directory-1.1.0.2 ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package file-embed-0.0.4.3 ... linking ... done.
Loading package process-1.1.0.1 ... linking ... done.
Loading package Cabal-1.14.0 ... linking ... done.
cabal: Error: some packages failed to install:
virthualenv-0.2.1 failed during the building phase. The exception was:
ExitFailure 11

Just wondering if anyone else is seeing this? On OS X 10.6.8, 64 bit. Haskell installed via the June '12 Haskell platform.

better arg parsing

move generic arg parsing to a different module
add options to auto-generate usage files
add automatic handling of --verbose/--version arguments
add option for short options with an argument (like -isrc)

Cannot deactivate virthualenv inside screen/tmux

If I activate a virthualenv in a shell and then start screen or tmux, the virthualenv persists and I can use it as normal, as I would expect. However, I cannot deactivate it as the deactivate function is not exported by bin/activate. I would recommend exporting that function, but I don't know if that would have other undesirable consequences, and I haven't yet had a chance to test it out.

I think we should either find a way to safely and robustly deactivate from within screen/tmux or at least make it explicit in the documentation that it can't be done.

use indentMessages in a more structured way

use user's cabal config (with adjusted settings) instead of dummy skeleton

name change to hsenv

when installing ghc switch cwds in a bracket

otherwise, when an exception is thrown in the middle, cwd is not restored and log file gets created in the wrong directory

``char-list-to-string`` not defined in Emacs 24

First, thanks for the awesome package. It made my day!

I'm trying the Emacs script, but I'm getting the following:

equal: Symbol's function definition is void: char-list-to-string

I'm running Emacs 24 on MacOSX. Thanks!

move cabal/hackage pkg index files instead of updating

fix finding real program in wrappers

cabal wrapper should find real cabal further down the PATH (to handle installing new cabal-install in the env) it should check for cabal binary in every path element (but discard itself) to handle situation where .virthualenv/bin is not the first element on the PATH

inherit of overrides in ~/.cabal/config?

When trying to compile with profiling, I was trying to install profiling versions of libraries, and overrode:

-- library-profiling: True

in ~/.cabal/config. But it seems that the library install with profiling only happens if I run cabal with:

cabal --enable-library-profiling install

Could overridden entries be observed runtime or copied during the creation of the .virthualenv/cabal/config?

Thanks

share hackage pkg cache with user's one

support multiple envs in one project directory

Thanks for virthualenv. I'd like to use it to test a project with different ghc and package sets, without having to duplicate the project directory. The --name option didn't do what I expected - virthualenv always uses the ".virthualenv" path. Here's a bash alias I use for switching, but making --name set the directory name seems better.

# activate the named .virthualenv environment ("deactivate" to exit)
function activate ()
{
    if [ "$1" == "" ]
    then
        echo environments available: `ls -d .virthualenv-*`
    else
        rm -f .virthualenv
        ln -s .virthualenv-"$1" .virthualenv
        source .virthualenv-"$1"/bin/activate
    fi
}

add emacs integration

MyMonad should export things like throwError, asks

write a readme file

use getopt for cli arg parsing

test shell code in bash/bash --posix/dash/zsh/ksh

catch exceptions when installing optional pkgs fails (e.g. haskell2010)