Hi folks. The streaming library hasn’t had a release in some time (itself not a problem; the library is stable), but it’s starting to fall behind the version windows of some major dependencies like mtl. This means it can’t be included as-is into the Stackage nightly snapshot.
Given how critical streaming is to many people’s dependency graphs, we’d like to bring this repo up to the same standard as used in streaming-bytestring, namely:
Please let us know your thoughts.
Releated PR: Transition to Github Actions by fosskers · Pull Request #120 · haskell-streaming/streaming · GitHub
16 Likes
These sound like good actions to take! I’m not sure why you’re asking Discourse though 
Aren’t they just standard maintenance practices?
I’ve actually seen someone reference this as a sign that streaming isn’t a viable choice, which is of course silly.
There’s ofc a case for cabal-level maintenance, but that shouldn’t really be a blocker to anyone in an age where it’s trivial to fix/ignore those things yourself no matter your 2023 Haskell build system choice.
I thought it would be good to ask around once on here before making bigger moves. I do have maintainer rights for streaming-bytestring but not for streaming, otherwise I’d just go ahead with it.
I have maintainer rights for streaming and would be happy to improve things. Could you open some issues with specifically what you have in mind, and we can take it from there?
5 Likes
Hi! Please see the attached PR. Luckily it looks like the dep bounds were already bumped (but not released), so that’s a free improvement. Basically I’m hoping to bring streaming and streaming-bytestring more into lockstep, since they’re often used together.
1 Like
I have about 50% of a streaming-text module written; as I was hoping to use streaming attoparsec on text instead of bytes.
It also took a few weeks to merge through a patch in the cassava wrapper which meant the last line could be silently dropped.
1 Like