yesod-1.4 barely installable from hackage

[gregwebs]

I think this issue really rears its head when you install alex and happy.
freckle/yesod-auth-oauth2#15

It is good that our install instructions suggest hackage, but

• stackage is not useable with a sandbox, which is needed for isolation on Windows
• leaving stackage can be necessary to install newer versions of packages

Can we generate a cabal.config from the stackage dependencies? That will allow it to be used with a sandbox. When someone is leaving stackage they can tweak the cabal.config

[snoyberg]

I don't understand that issue to be honest, so I'm not sure what Alex and
happy have to do with things. Your first point is true, but the second is
not. An inclusive Stackage snapshot will address that use case.

On Saturday, October 18, 2014, Greg Weber notifications@github.com wrote:

I think this issue really rears its head when you install alex and happy.
freckle/yesod-auth-oauth2#15
freckle/yesod-auth-oauth2#15

It is good that our install instructions suggest hackage, but

• stackage is not useable with a sandbox, which is needed for
  isolation on Windows
• leaving stackage can be necessary to install newer versions of
  packages

Can we generate a cabal.config from the stackage dependencies? That will
allow it to be used with a sandbox. When someone is leaving stackage they
can tweak the cabal.config

—
Reply to this email directly or view it on GitHub
#853.

[snoyberg]

I also just added a feature to stackage which might help you. If you go to any snapshot page, it will give you a link called cabal.config that will provide the constraints I think you're asking for. For example:

http://www.stackage.org/stackage/7b1cb620bf6ee03b2709b7e9c17682fb47530c36/cabal.config

Pinging @chrisdone. We might want to consider advertising that feature for people who can't use hsenv.

[chrisdone]

I'd agree. On two occasions I've had people who seem to refuse/not use hsenv and so I've had to manually generate a cabal freeze constraints file. This feature seems like a very good idea to me.

[snoyberg]

Note that it's not quite as powerful as a normal Stackage exclusive snapshot, since it will allow other non-Stackage packages in. In that sense, you could think of it as a way to convert an exclusive snapshot into an inclusive one. It's still far better than nothing, of course.

Let's talk on Monday about how to explain this to people.

[gregwebs]

Perfect! I would suggest having a 7.8.3-latest alias and explaining it as

cabal sandbox init
curl http://www.stackage.org/stackage/7.8.3-latest/cabal.config > cabal.config
cabal install --only-dep

An application developer will then want to freeze their dependencies.

cabal freeze
git add cabal.config
git commit cabal.config

The last step is for application developers, not library developers. Upgrading multiple dependencies with a cabal.config can be a tricky process. Similar to installing, the stackage snapshot can help again

rm cabal.config
curl http://www.stackage.org/stackage/7.8.3-latest/cabal.config > cabal.config
cabal install --only-dep --force-reinstalls

This is a conservative upgrade. For an aggressive upgrade, wipe out your sandbox before installing.

rm -r .cabal-sandbox
cabal sandbox init

[gregwebs]

I don't understand that issue to be honest, so I'm not sure what Alex and
happy have to do with things

If you also install alex & happy into the sandbox rather than into ~/.cabal/bin that can make the difference as to whether cabal can figure out how to install things.

but the second is
not. An inclusive Stackage snapshot will address that use case.

The documentation states

foo-1.0 will not be included in either snapshot

I took this to mean that foo-2.0 is not in either also. Perhaps I am misunderstanding how it operates.

[snoyberg]

You're right. I misread and took it to mean packages not in stackage.
Rereading this thread, it's clear that's not what you were talking about.

On Saturday, October 18, 2014, Greg Weber notifications@github.com wrote:

I don't understand that issue to be honest, so I'm not sure what Alex and
happy have to do with things

If you also install alex & happy into the sandbox rather than into
~/.cabal/bin that can make the difference as to whether cabal can figure
out how to install things.

but the second is
not. An inclusive Stackage snapshot will address that use case.

The documentation
https://github.com/fpco/stackage/wiki/Stackage-Server-FAQ#whats-the-difference-between-inclusive-and-exclusive-snapshots
states

foo-1.0 will not be included in either snapshot

I took this to mean that foo-2.0 is not in either also. Perhaps I am
misunderstanding how it operates.

—
Reply to this email directly or view it on GitHub
#853 (comment).

[snoyberg]

And the following should work as a permalink:

http://www.stackage.org/alias/fpcomplete/unstable-ghc78-exclusive/cabal.config

[gregwebs]

Are you ready to expose this to the world? Want me to write a blog post about it and review it?

[snoyberg]

Yes, please do, that would be great. It's certainly ready for primetime.

[dominikmayer]

I have yesod installed and could run runhaskell helloworld.hs from the book. For whatever reason it stopped to work (Could not find module ‘Yesod’) and now I've spent the whole day trying to reinstall the package.

It does not work with standard cabal:

yesod-1.4.1 depends on streaming-commons-0.1.6 which failed to install.

If I change the remote-repo to Stackage it doesn't work either:

yesod-1.4.1 depends on xml-types-0.3.4 which failed to install.

What can I do or where can I find help?

[snoyberg]

At the very least we'd need the actual error logs. If using Stackage failed, my guess is that you have some previously installed packages still lying around which are causing problems. You'll likely need to wipe our your old ~/.ghc database and start over. If after doing that the problem persists, please create a separate issue.

@gregwebs I think this issue itself should be closed, any objection?

[gregwebs]

@dominikmayer sorry for your troubles. It is usually best to post about install issues on the yesodweb mail list. I am closing this issue because the original intent was to provide better install instructions related to stackage.

[dominikmayer]

@gregwebs No problem. I've renamed ~/.ghc and see if this works. Where can I find that mailing list? I couldn't find it on the website or in the wiki. I'm very new to Haskell and Yesod and don't yet know how it all fits together.

[dominikmayer]

I found it. (And the build failed again :-()

[alonecuzzo]

@dominikmayer I'm getting this error as well, (Could not find module ‘Yesod’. Did you ever find a solution?

[erikd]

@alonecuzzo :

• What version of ghc and cabal-install are you using?
• When did you install them?
• Are you using a cabal sandbox and if not, do you know how to purge your cabal installed packages?

[dominikmayer]

I haven't found a solution and stopped trying. Sorry. But I think @snoyberg is working on an easy way to get you started.

[gregwebs]

@alonecuzzo @dominikmayer use stack and let us know what issues you are having.

[erikd]

@dominikmayer I don't think stack is the only solution. I ask you the question I asked @alonecuzzo;

• What version of ghc and cabal-install are you using?
• When did you install them?
• Are you using a cabal sandbox and if not, do you know how to purge your cabal installed packages?

[dominikmayer]

I don't remember. I had the problem almost one year ago and went with another language and another framework when I couldn't get yesod working.