Snap-loader on stackage

[rjayatilleka]

Hey I'm just opening an issue here since this is the primary issue tracker listed on your website. I opened a couple issues on the snap-loader-static and snap-loader-dynamic repos. Can we get them added to stackage? I can't build them with stack right now without adding the dependencies manually. Or is there a reason they're not on stack?

[bitemyapp]

@rjayatilleka have you tried adding them to extra-deps? Stack can pull libraries from Hackage too.

Examples here: https://github.com/commercialhaskell/stack/wiki/FAQ

[rjayatilleka]

Yeah I know, that's what I did.

I can't build them with stack right now without adding the dependencies manually.

But the issue is for getting the snap-loader packages on stackage. Heist, snap, snap-core, and snap-server are all on stackage. Is there a reason the snap-loader packages can't enter stackage?

[bitemyapp]

@rjayatilleka Stackage requires coordination from package maintainers to sync up their upper and lower bounds with each "generation" of Stackage. I do this for Bloodhound and I don't mind, but critically, I only have one isolated library to maintain.

This could be substantially more burdensome for an entire package sub-ecosystem like Snap.

What you're asking for is potentially (I can't say for sure) pretty costly in terms upfront time investment and means having to do periodic dep-bump releases whenever you're out of step with the rest of Stackage.

Multiple those dep-bump releases by $n packages... - I think you see my point.

Again, I don't mind having Bloodhound on Stackage and I'm pretty excited about Stack myself, but if this doesn't go anywhere with the Snap developers (I'm not one myself) the reasons I outlined might be among the reasons they're not interested.

[rjayatilleka]

Yeah sure I totally understand that its up to the discretion of the package owners whether or not to maintain it in Stackage. I just want to make sure it wasn't just an oversight, or bring it up for a recorded explanation if it was a deliberate decision.

Well, this isn't at all an urgent problem so I don't think there's anything left to discuss here. I'll just keep this open until the Snap developers leave a response. They can close it on their own if they want. Thank you for the response, and apologies if my earlier reply was too blunt or rude.

[bitemyapp]

@rjayatilleka No problem! I'm sure they're aware of it, but might have other things that are more pressing.

One option you might consider is asking Snoyman on the Stackage project as I think he actually adopted the Snap packages for inclusion into Stackage himself so that the Snap devs didn't have to. He might've merely missed those packages and if you ask him, you may get what you want.

Hope this helps 🐻 😄

[mightybyte]

Like Chris said, I wasn't the one to originally add the snap packages to stackage. He also describes the coordination issues pretty well. In fact, right now snap and heist are blocking stackage because of the large breaking change introduced in errors-2.0. There are multiple directions we can go to fix it and it's difficult because we have a policy of maintaining backwards compatibility with the last three haskell platform releases. So the upgrade is a significant amount of work and I haven't had the time to get to it yet. We'll fix it eventually, but in the meantime things still work fine with errors-1.x.

I saw the issues on the other packages, but I was out of town for awhile and hadn't had a chance to respond. I'm going to close this issue since it's not the right place, but I'll leave the other issues open for now until I decide what to do.