paczesiowa/hsenv

Virtual Haskell Environment builder

hsenv's Issues

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

Use a different command name for `deactivate`

Because it conflict with python's virthalenv, and i need to develop python and haskell together, i find this conflict very annoying.

move cabal/hackage pkg index files instead of updating

add option to use already installed ghc

e.g. custom, hacked version of ghc

use indentMessages in a more structured way

check haddock situation

use tar library instead of calling system's tar

Util.Tar module seems to work fine, but reading ghc tarballs fails because tar library cannot read gnu tar format with LongLink extension. without it, it extracts truncated file names (to 100 chars)

"Couldn't parse package identifier depends" output nothing

When I execute the installed hsenv, it will generate nothing in the .hsenv/bin dir and dump errors both in log and stderr :

_( from sterr )_
Creating Virtual Haskell directory structure
Installing GHC
Initializing GHC Package database at /tmp/testenv/.hsenv/ghc_pkg_db
Copying necessary packages from original GHC package database
Couldn't parse package identifier depends:

hsenv.log file contains detailed description of the process.

I've check the hsenv.log file, and it shows the error was caused by Cabal-1.14.0 which had been installed by cabal-install :

Copying package Cabal-1.14.0 to Virtual Haskell Environment
    _(... ignore many ENV outputs)_
    Process error output:
        ghc-pkg: cannot find package Cabal-1.14.0
It's not.
Extracting dependencies of Cabal-1.14.0
    Running system's version of ghc-pkg
      Executing: ghc-pkg field Cabal-1.14.0 depends
        using inherited variable environment
        Process exited successfully
        Process output:
          depends: array-0.4.0.0-59d1cc0e7979167b002f021942d60f46
                   base-4.5.0.0-40b99d05fae6a4eea95ea69e6e0c9702
                   _(... ignore many depends outputs)_
          depends: array-0.4.0.0-59d1cc0e7979167b002f021942d60f46
                   base-4.5.0.0-40b99d05fae6a4eea95ea69e6e0c9702
                   _(... ignore many depends outputs)_
        Process error output:
    Found dependency strings:  _( it's a horrible long string)_

Couldn't parse package identifier depends:

The last line should output something, but it didn't . And the ghc-pkg check command can only find some warnings about haddock . This problem has been reported in the pre-renaming virtualenv repo , and it still open .

My platform :

• Ubuntu 12.04 server
• GHC 7.4.1
• cabal-install_0.10.2-3_amd64.deb

And the hsenv.cabal file had been modified to fit new dependencies . I admit that may cause problems, but my situation is nothing output from a line, which should print what's wrong happened .

release to hackage please

use builddir param for cabal wrapper

cabal should use --builddir=foo param (using env's name?) to build in custom directory per environment, so if the user uses many environments to build the same copy of package it shouldn't do so many rebuilds.

add exception wrapper

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

automatically source when moving into the directory

see Paczesiowa/virthualenv#33

global cache of installed environments

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

Unable to install tarballs with '~' in the path

In revision f14cddf I'm unable to create an environment with the home directory shortcut ('~'):

$ /.cabal/bin/hsenv --ghc=/packages/ghc-7.5.20120711-x86_64-unknown-linux.tar.bz2
Creating Virtual Haskell directory structure
Installing GHC
Installing GHC from ~/packages/ghc-7.5.20120711-x86_64-unknown-linux.tar.bz2
/bin/tar process failed with status 2

hsenv.log file contains detailed description of the process.

$ cat hsenv.log
Creating Virtual Haskell directory structure
hsenv directory: /data/home/chee1/breakghc/.hsenv_breakghc
cabal directory: /data/home/chee1/breakghc/.hsenv_breakghc/cabal
hsenv bin directory: /data/home/chee1/breakghc/.hsenv_breakghc/bin
Installing GHC
Installing GHC from ~/packages/ghc-7.5.20120711-x86_64-unknown-linux.tar.bz2
Unpacking GHC tarball to /data/home/chee1/breakghc/ghc31404
Running outside process: tar xf ~/packages/ghc-7.5.20120711-x86_64-unknown-linux.tar.bz2 -C /data/home/chee1/breakghc/ghc31404 --strip-components 1
Looking for tar in $PATH
tar -> /bin/tar
Process failed with exit code 2
Empty process output
Process error output:
/bin/tar: ~/packages/ghc-7.5.20120711-x86_64-unknown-linux.tar.bz2: Cannot open: No such file or directory
/bin/tar: Error is not recoverable: exiting now

/bin/tar process failed with status 2

$ rm -rf .hsenv_breakghc/

$ /.cabal/bin/hsenv --ghc=/home/chee1/packages/ghc-7.5.20120711-x86_64-unknown-linux.tar.bz2
Creating Virtual Haskell directory structure
Installing GHC
Installing GHC from /home/chee1/packages/ghc-7.5.20120711-x86_64-unknown-linux.tar.bz2
Initializing GHC Package database at /data/home/chee1/breakghc/.hsenv_breakghc/ghc_pkg_db
Copying necessary packages from original GHC package database
Using user-wide (/.cabal/packages) Hackage download cache directory
Installing cabal config at /data/home/chee1/breakghc/.hsenv_breakghc/cabal/config
Installing activate script
Installing cabal wrapper using /data/home/chee1/breakghc/.hsenv_breakghc/cabal/config at /data/home/chee1/breakghc/.hsenv_breakghc/bin/cabal
Skipping 'cabal update' step, Hackage download cache already downloaded
to ~/.cabal/packages/. You can update it manually with 'cabal update'
(from inside or outside the virtual environment).

To activate the new environment use 'source .hsenv_breakghc/bin/activate'

I'm guessing that there is a missing environment variable, maybe $HOME missing.

get rid of non-tarball ghc usage

it's buggy (see #18 ), and adds a lot of code. implement sharing of installed ghc copies (perhaps something like ~/.hsenv/ghc/7.4) first to make it more efficient (disk space and creation time wise)

share hackage pkg cache with user's one

support multiple envs in one project directory

see Paczesiowa/virthualenv#34

Is Paczesiowa still maintaining it?

Hello there,

I'm a long time hsenv user, and I've always found it to be a life saver against cabal's hell.
I'm a little upset to see that apparently despite a lot of active development from forks, the main repo is slightly outdated now and rarely updated (last merge 4 mo ago).

In a moment where we have ghc 7.6.1 and cabal 1.16 out, is very important to keep the right pace to be aligned with these new technologies.
I obviously understand that OSS is the product of passion and free time, so @Paczesiowa have all the reasons in the world to not have time to updated it, what I'm wondering if he can give write access to the repo also to someone else so that the project can be updated :)

(Maybe create a new organisation so you can selectively entitle people to read/write access?)

Good luck!
A.

cabal: HOME: does not exist in HEAD. OSX 10.7, GHC 7.4.2 i386 and x86_64

get this error on

As of this commit (but possible earlier), 47621c7, i get this error:

  $PATH=/Users/max/development/raise-internal/raise-launch/.hsenv_raise-launch/cabal/bin:/Users/max/development/raise-internal/raise-launch/.hsenv_raise-launch/ghc/bin:./cabal-dev/bin:/Users/max/.cabal/bin:/usr/local/bin:/usr/local/sbin:/opt/local/bin:/opt/local/sbin:/Users/max/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/max/Library/Haskell/bin:/Users/max/bin:/Users/max/bin/play:/bin
Process failed with exit code 1
Empty process output
Process error output:
  cabal: HOME: does not exist

/usr/bin/cabal process failed with status 1

rolling back to 80eb47b resolved the issue. looks like something with the new process manager.

test hsenv.el with emacs24

Process.runProcess should only log env diffs

runProcess currently logs the whole environment (if Just env is used), it should only log the differences against the parent environment. the master/parent environment should be logged whole at the beginning.

hsenv does not respect 'jobs' configuration variable in Cabal 1.16

After fixing hsenv with GHC 7.6.1 and cabal-install 1.16 (cc #31) I tried installing something like 'trifecta' and it installed it serially, while my ~/.cabal/config contains:

jobs: 12

If I deactivate my environment, and install trifecta with regular GHC, cabal automatically parallelizes the installation.

Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal

After upgrading to GHC-7.6.1 I get the following error after creating and activating the hsenv environment and then running cabal configure:

$ cabal configure
Resolving dependencies...

on the commandline: Warning:
    -package-conf is deprecated: Use -package-db instead
[1 of 1] Compiling Main             ( Setup.hs, dist_usb/setup/Main.o )
Linking ./dist_usb/setup/setup ...
Configuring usb-1.1.0.2...
setup: 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).

$ cabal --version
cabal-install version 0.14.0
using version 1.14.0 of the Cabal library

After removing the export of GHC_PACKAGE_PATH from the activate script, cabal works. Maybe a better approach is to temporarily unset the GHC_PACKAGE_PATH in the cabal wrapper script and afterwards export it again.

Add a --remote-repo option

I use a Hackage mirror to avoid outages, but when hackage is down my hsenv commands always break at the end because cabal update fails. It would be nice if I could point hsenv at the mirror, so that the update would succeed.

cabal bootstrapping

Finish transition from mercurial to git

It would be nice to have dist in the .gitignore instead of a .hgignore

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)

Let the cabal build "dist" directory alone

Hi,

I don't know if this is a specifc hsenv issue of is related to the way cabal works or is sandboxed. A common problem an hsenv user has is that cabal build puts its output in the dist directory. With hsenv activated instead, the fold is renamed dist_<env-name>.

The problem is that this breaks a lot of scripts (for example the ones Snap framework uses for running test coverage), because this scripts expect to find the dist directory, without the trailing suffix.

One solution is to symlink the dist_<env-name> to point to dist, but this solution is not elegant due to the fact it binds the script to the presence of hsenv. The process should be agnostic.

How to reproduce it:

• Activate an environment and inside it go with cabal configure and cabal build

Expected Behaviour:

• Files got compiled inside dist folder, regardless to the environment name

Real Behaviour:

• Files are put inside a folder called dist_<env-name>

Cheers,
Alfredo