Stack lts version is 0.4.1 about brick HOT 13 CLOSED

Ultimately I don't have any control over the version of my library that goes into various versions of Stackage. Your report made me remember that I actually intended to remove my packages from Stackage entirely. (I realize that's kinda the opposite of what you wanted, but they have now been removed.) I recommend just using the version that's on Hackage.

I'm glad you're getting value out of the library!

from brick.

Wait a moment, that is indeed the opposite of what I intended. I know, that I can use stack with hackage packages, but I have always thought, that that was mainly for less stable packages, which shouldn't be used with production code. Could you at least explain that move?

from brick.

Nothing about hackage is specifically about less stable packages. Stackage is one way to get a stable collection of packages, but it is not necessary to use Stackage to do this. (cabal freeze, for example, is a perfectly good way to deal with reproducible builds for production purposes.)

My decision to add my packages to Stackage was experimental at best, and I'm finding out that "supporting" Stackage for my packages is awkward because I have no control over what Stackage does. I also do not use it myself and have no intention of doing so for various reasons, so I have been planning on removing my packages from it because it's hard to claim I support it when I don't use it or follow it.

I understand this isn't what you wanted. You filed this issue at a strange time when I had been meaning to make this change but hadn't gotten around to it. :) As you pointed out, if Stackage is important to you then you can use it with Hackage packages. If you want to explore just using Hackage, the new cabal new-build features are a promising alternative and I think cabal freeze is definitely worth consideration.

from brick.

Thank you!

from brick.

Drat! I hope someone adds brick to stackage again in future. It's a key piece of hledger-ui, and having it in stackage increases the likelihood that it's included and up to date in distro package systems, and increases the chance that a new haskeller trying to install a brick-based app from source will have a good experience.

from brick.

Isn't it possible to install stack-enabled sources using sources that are only available on Hackage?

from brick.

And for what it's worth, it would be awkward if someone other than me put one of my libraries in stackage. :)

from brick.

Yes, that works when building from source, though it adds more possible failure modes (hackage downtime, less build plan testing, less screening of malicious uploads)

On Jul 11, 2016, at 14:27, Jonathan Daugherty [email protected] wrote:

Isn't it possible to install stack-enabled sources using sources that are only available on Hackage?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

from brick.

Not if you were ok with it.

On Jul 11, 2016, at 14:27, Jonathan Daugherty [email protected] wrote:

And for what it's worth, it would be awkward if someone other than me put one of my libraries in stackage. :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

from brick.

I don't think the drawbacks you mentioned are likely/significant enough to outweigh my opposition to using and supporting stack and Stackage. (And being opposed, I wouldn't want my packages added on my behalf because that represents a support promise that someone would be making on my behalf.)

from brick.

@jtdaugherty: are you actually opposed to stackage, rather than just short of time ? That would make me sad.

Happily for stackage users, I see brick-0.6.4 landed in stackage nightly-2016-05-26 (GHC 7.10) and brick-0.7.1 in nightly-2016-05-28 (GHC 8.0). There's no entry for it in stackage's build-constraints.yml; I think it is included automatically because another stackage package depends on it, and because it builds, and in this situation the package maintainer has no responsibility for keeping it working in stackage.

from brick.

I'm opposed to stackage and stack on both technical and social grounds.

from brick.

I see, I'm sorry to hear that.

from brick.