Themes for 1.22

2014-04-24 Thread Johan Tibell
Hi all, While I'm sure we still have a bugfix release or two to make on the 1.20 branch, I thought it'd be worth looking at what we want to accomplish for 1.22. Here are my thoughts on what we should focus on: ## A dependency solver that always works As Hackage has grown so have the

Themes for 1.22

2014-04-24 Thread Benjamin Edwards
Hi Johan, Not sure if this mail is a request for comments, but on the story for large projects one thing that I would like to see is the ability to add packages that aren't in hackage to the depends list. I agree that adding some scanning and auto add ability is definitely sorely needed, but this

Re: Themes for 1.22

2014-04-24 Thread Erik Hesselink
You can handle this scenario pretty easily by setting up a private hackage. Then add a second remote-repo to your cabal config, either globally or in the sandbox. We do this, and it works pretty well. Regards, Erik On Thu, Apr 24, 2014 at 1:33 PM, Benjamin Edwards edwards.b...@gmail.com wrote:

Re: Themes for 1.22

2014-04-24 Thread Benjamin Edwards
I will definitely look into that! Thank you. The one your that does force you down though is the path only developing against releases, and even those are light-weight internal patch releases to your own hackage it still means a longer compile-test cycle. Maybe if that's a problem it indicates

Re: Themes for 1.22

2014-04-24 Thread Johan Tibell
Having to share code via releases is indeed the problem with an internal Hackage. I don't see that scaling well as an organization gets bigger. You really need to be able to check out the organization's source repo and have that contain a bunch of (non-released) packages and build them together.

Re: Themes for 1.22

2014-04-24 Thread Gregory Collins
I'd like to add to the list: change cabal-install so that most of its code is exported to hackage as a library. In the past I've occasionally wanted to do some of the same things the cabal binary does from code, and it would be much more convenient to link the relevant code in than to exec the

Re: GenericPackageDescription and 'build-depends' field

2014-04-24 Thread Mikhail Glushenkov
Hi, On 21 April 2014 13:47, Daniel Trstenjak daniel.trsten...@gmail.com wrote: On Thu, Apr 10, 2014 at 03:10:32AM +0200, Mikhail Glushenkov wrote: IIRC it's what condtrees get simplified to after finalizePackageDescription. What's the reason for this? Condtrees represent conditional blocks