Re: [snap] Help me to get the general overview of the testing workflow

[Gregory Collins]

On Mon, Sep 17, 2012 at 3:10 PM, Alfredo Di Napoli <alfredo....@gmail.com> wrote:

Hi,

I'm basically trying to help with snap, but the project size is huge and it's easy to get overwhelmed.
I've fixed a little bug (see issue #30 on github) and I would like to test the code I wrote, but I'm struggling with the test setup:

a) I use hsenv to manage my sandboxed environment: by default, it build every cabal package in dist_$HSENV_NAME instead of simply "dist".
    This creates problem with scripts like runTestsAndCoverage.sh which search inside "dist". The problem can be easily solved using a symlink,
    but it becomes annoying pretty soon, because in order to make the cabal-dev tests compile, you have to symlink every other directory snap is
    bound to, for example heist, snap-core, snap-server, xmlhtml, etc, etc. I hope the issue is clear.

The best way to go here is to modify your local copy of the test shell script. There's not any magic in there. If you can modify the scripts to read the distdir location from an environment variable (defaulting to "dist" of course), that would be acceptable.

 

b) Don't know if it's only my impression, or the sandboxed, cabal-dev based tests are very heavy to compile, I also guess due to the "-O2" option.
    Is there any way to make the testing process faster?

The snap project generates complete projects, and the only way to test that those are generated correctly, using the latest development versions of the libraries, is to build them from scratch. So no.

 

c) Don't know why, but once every cabal-dev env is ready, builded and deployed, the script (runTestsAndCoverage.sh) simply fails to locate the executable:
    This is what I've got on my machine:

Linking dist_snap/build/tutorialTest/tutorialTest ...
Installing executable(s) in
/root/programming/haskell/snap/snap/test/test-cabal-dev//bin
Running "./dist/build/tutorialTest/tutorialTest -p 9992"
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)     <----- this is probably related to a deficiency of my pc :D
/bin/sh: ./dist/build/tutorialTest/tutorialTest: No such file or directory
  snap/tutorial: [Failed]
ERROR: connect: does not exist (Connection refused)

But the executable exists, but is in <my_path_to_snap>/test/test-cabal-dev/bin! Is this also due to the fact I'm using Hsenv?

Probably. And, since you're the only one, you're on your own re: figuring out how to make it work. Try using the stock tools instead.

 

If you think It can be useful to solve those issues, and therefore make the project hsenv compliant in a non-invasive way, I'm willing to help. 
I could simply modify slightly some scripts or maybe add some post build hook to automatically symlink the output build dir with dist.
In case you don't want to have this kind of dependency from a particular sandboxed env, suggestion about how to fix my problems are
welcome. What I would like to achieve is a solution that will allow me to simply enter the test directory of snap, typing cabal configure && cabal install && ./runTestsAndCoverage.sh
and simply have green all around :)

That is exactly how it works with the stock cabal. I guess hsenv is wrapping "cabal" such that it behaves differently than the stock version? In that case, it's unlikely the test suites/etc will work in that scenario as written (as you've discovered).

G

P.S. thanks for making the effort to help out :)

-- 

Gregory Collins <gr...@gregorycollins.net>

[mightybyte]

On Monday, September 17, 2012 9:49:57 AM UTC-4, Gregory Collins wrote:

On Mon, Sep 17, 2012 at 3:10 PM, Alfredo Di Napoli <alfredo....@gmail.com> wrote:

Hi,

I'm basically trying to help with snap, but the project size is huge and it's easy to get overwhelmed.
I've fixed a little bug (see issue #30 on github) and I would like to test the code I wrote, but I'm struggling with the test setup:

a) I use hsenv to manage my sandboxed environment: by default, it build every cabal package in dist_$HSENV_NAME instead of simply "dist".
    This creates problem with scripts like runTestsAndCoverage.sh which search inside "dist". The problem can be easily solved using a symlink,
    but it becomes annoying pretty soon, because in order to make the cabal-dev tests compile, you have to symlink every other directory snap is
    bound to, for example heist, snap-core, snap-server, xmlhtml, etc, etc. I hope the issue is clear.

The best way to go here is to modify your local copy of the test shell script. There's not any magic in there. If you can modify the scripts to read the distdir location from an environment variable (defaulting to "dist" of course), that would be acceptable.

If you do this, just make sure you either don't commit your changes or you do it in a portable way such that it will still work for people building with cabal.

 

 

b) Don't know if it's only my impression, or the sandboxed, cabal-dev based tests are very heavy to compile, I also guess due to the "-O2" option.
    Is there any way to make the testing process faster?

The snap project generates complete projects, and the only way to test that those are generated correctly, using the latest development versions of the libraries, is to build them from scratch. So no.

This is the price of code generation.  Testing becomes much more expensive.

 

[Alfredo Di Napoli]

If you do this, just make sure you either don't commit your changes or you do it in a portable way such that it will still work for people building with cabal.

 

I think I'll simply try to stick with cabal-dev :)

Exploiting everyone's kindness, which is the "idiomatic" way to setup a sanbox with cabal-dev?

My project root is something like this:

snap-dev +/

    heist

    snap-core

    snap-server

    snap

    [..]

Where those folders either forked or cloned from github.

I thought about 2 options:

a)  (inside snap-dev) cabal-dev install, then add every package with cabal-dev add-source

b) Create a cabal-dev env inside EVERY folder, then from the snap folder:

    cabal add-source ..<every directory in the ancestor dir>

    

a or b? :)

A.

[MightyByte]

I actually don't use cabal-dev for my development.  I typically just use cabal/cabal-install and if I have a complex project with a number of local dependencies that aren't on hackage, then I use cabal-meta.

We use cabal-dev in the test suite because it has sandboxes, but I haven't seen a huge need for sandboxes in my day-to-day development.

[Alfredo Di Napoli]

I actually don't use cabal-dev for my development.  I typically just use cabal/cabal-install and if I have a complex project with a number of local dependencies that aren't on hackage, then I use cabal-meta.

We use cabal-dev in the test suite because it has sandboxes, but I haven't seen a huge need for sandboxes in my day-to-day development.

Uhm, and how you take shelter from potential cabal dep hell?

I mean, I can be happen using a non-sandboxed env, right? I just though a sandbox env was the cleaner way to go in general :)

Bye,

A. 

[MightyByte]

I found that cabal-dev doesn't work as well with ghci.  I don't actually encounter dep hell all that often, and when I do a simple "rm -fr ~/.ghc" usually fixes the problem.  When that isn't sufficient, I've found cabal-meta to be the perfect answer to the other issues I've encountered.  See my comments here.

http://www.reddit.com/r/haskell/comments/rurn4/cabalmeta_transcending_to_dependency_heaven/c496e5y

[Alfredo Di Napoli]

I found that cabal-dev doesn't work as well with ghci.  I don't actually encounter dep hell all that often, and when I do a simple "rm -fr ~/.ghc" usually fixes the problem.  When that isn't sufficient, I've found cabal-meta to be the perfect answer to the other issues I've encountered.  See my comments here.

http://www.reddit.com/r/haskell/comments/rurn4/cabalmeta_transcending_to_dependency_heaven/c496e5y

I see. I guess I have to play a little with various options.

Yesod folks uses the combined approach of hsenv + cabal-meta, so I thing it's a duo worth looking at.

Besides that, the new package hellno can be worth a try.

I'll keep you posted.

A. 

[Janne Hellsten]

In order to help out others like me who are new to working with the development version of Snap, here's instructions on how to setup & build the latest Snap from github using cabal-meta.

$ mkdir snap-dev

$ cd snap-dev

Create a file called sources.txt that contains:

8<

snap/

snap-core/

snap-server/

heist/

8<

Clone all the repos:

$ git clone -b 0.10 git://github.com/snapframework/snap.git 

$ git clone git://github.com/snapframework/snap-core.git

$ git clone git://github.com/snapframework/snap-server.git
$ git clone git://github.com/snapframework/heist.git

Build using cabal-meta (w/ a local cabal-dev sandbox):

$ cabal-meta --dev install

If you want a sample project to work with, you can use snap init default to create a test project at the snap-dev root:

$ ./cabal-dev/bin/snap init default

To build it, add ./ to your sources.txt:

8<

./

snap/

snap-core/

snap-server/

heist/

8<

..build:

$ cabal-meta --dev install

..and run it:

$ ./cabal-dev/bin/snap-dev

Success!

Janne