Stack support

[sw1sh]

RIght now in order to include HLearn in my project I have to list many packages inside stack.yaml file to meet all its dependencies, this creates custom sandbox and kinda annoying. Would be great if HLearn could be build against some stackage snapshot, lts-3.0 for example.

[varosi]

+1

[mikeizbicki]

This is a great idea. I don't personally use stack, so I'm probably not the best person to make these changes to the config file. But if anyone wants to do this, I'd happily merge the pull request.

[rkarp]

The problem is simply all these fixed versions. There is no way to create a stack.yaml with few extra-deps for subhask due to this.

[mikeizbicki]

I didn't used to use fixed version dependencies like that, but it resulted in a number of bugs caused by subtleties in changed dependencies. The bugs were extra subtle because they were performance bugs, not semantics bugs. There are certainly other versions of these packages that would work, but I don't have time to figure out what they are.

The short answer is that I'm disinclined to go away from fixed version numbers, but I'd support changing what the fixed version is to something more standard.

[3noch]

Stackage uses fixed version numbers too. Moving to a known stackage snapshot would merely mean making your fixed versions match most of the published snapshot versions. If you use stack, then you can override whatever remaining packages don't follow the snapshot exactly, if necessary.

[mikeizbicki]

@3noch Exactly. I'm very enthusiastic about this type of change. I'm just not a stack user myself, so I wouldn't know what versions to specify or how to check that everything works with the stack ecosystem. But I'd gladly accept a pull request fixing this issue!

[freeman42x]

:+1:

[jimstutt]

Similar to rkarp I managed to build a previous version of subhask as a nix pkg on nixos. When hyperloglog was included as a dependency I couldn't get that to build as a nix pkg.

On Fri, Aug 28, 2015 at 9:14 PM, Răzvan Panda notifications@github.com wrote:

[image: :+1:]

— Reply to this email directly or view it on GitHub https://github.com/mikeizbicki/HLearn/issues/63#issuecomment-135889068.

[mikeizbicki]

I would be fine with removing hyperloglog if that's what's needed to get the versions standardized.

[varosi]

If that could help: https://www.fpcomplete.com/blog/2015/08/new-in-depth-guide-stack The key HLearn to be used more widely and in larger projects in my opinion is to support Stack-based building.

[mikeizbicki]

I've updated the dependencies of subhask and HLearn so that they're now compatible with stack's lts-3.3. At least I think. Again, I don't use stack as my primary build tool, so I'd appreciate if someone interested in the conversion would make sure I did it correctly.

[michaxm]

Works for me.

IMO the most important improvement for this project is the inherent specification of a compatible ghc version.

[mikeizbicki]

Works for me.

Great!

IMO the most important improvement for this project is the inherent specification of a compatible ghc version.

Could you clarify what you mean by this? There's always been an inherent GHC specification due to the constraints on the base package.

[michaxm]

"inherent" is the wrong word, I should have said "more obvious". On my first build attempt with 7.8 I was not sure, which package the problem was - base or whatever the conflict was with. Since it was my first conflict with base, I went in the wrong direction first. Stack is much more verbose on this matter.

[mikeizbicki]

Got it. Thanks again for letting me know stack works for you :)