-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove dependency on scalaz.concurrent #321
Comments
There are some things from Scalaz that we need above and beyond the concurrency primitives. Most notably, abstractions like Having full control over our own primitives would be great though. |
I've been considering this as well, and have scalaz-stream compiling on cats (requires publishLocal of cats). Todo.scala lays out what is needed to make it real.
It's not a small job, but it's viable. The big decision, as I see it, is whether the base abstractions are sourced from cats-core or scalaz-core. See also:
|
I'm also interested in a |
I'd rather just cut the dependency entirely, like @mpilquist has done for scodec. I do not want to move scalaz-stream from depending on scalaz to depending on cats (see below). Instead, I'd like to investigate:
The reason I'd rather just cut the dependency entirely is that I don't really want to pick sides in this whole mess of multiple projects competing to provide the same functionality. To the extent it is possible, I'd like whatever library "wins" to do so on its technical merits, not because of network effects by random projects like scalaz-stream choosing this or that library as their dependency. The only reason I've kept scalaz-stream depending on scalaz is when I last looked into it, it seemed pretty annoying to change. But, my head probably wasn't in it given how fried I was from dealing with scalaz drama, so I do think it's quite possible. That said if @pchlupacek and/or @rossabaker would like to investigate breaking the dependency entirely, I would heartily endorse that effort! :) I myself do not have the bandwidth to work on it right now, though. Now, the hardest part will be figuring out what to rename the project... :) Just to clarify, I am totally fine continuing to depend on scodec-bits. That is a rock solid and stable dependency. |
@pchiusano I am very happy to see this -- multiple repositories, one core along with one for each integration, sounds great. I'm happy to help with the conversion / dependency breaking. |
@pchiusano I would likely consider if we can't have core with 0 dependency. I like s-codecs, but perhaps having the bytes-xxx project as sort of module, may be more consistent. I understand that this is used only in io, so perhaps we may have io project that depends on s-codes. |
Yes, I should say, anyone with an interest in this is welcome to help out, not just @pchlupacek and @rossabaker. :) As a next step, I'd recommend that someone volunteer to take the lead in creating a new branch which removes scalaz as a dependency, and get a complete inventory of all the stuff missing. I'm guessing this branch will be in a noncompiling state for a while, but I'd still push the WIP in case it is possible to parallelize the work. (Like, we need |
I think I'd be okay with a multimodule project, with all the io stuff seprated, and it could depend on scodec-bits, with core having literally zero deps. But I don't have strong feelings either way. I feel pretty comfortable with the scodec-bits dependency just because it is so stable and slow-moving. If we were to do the separate io module, I'd do that as a separate effort from removing the scalaz dependency - they are orthogonal. |
yeah, was really just a proposition I am ok with this as it is as well. Is like removal of dependency on scala almost :-) |
I'm definitely up for exploring the typeclass-lib-agnostic approach. It sounds wonderful on paper, but I envision many important functions will be exiled to duplicated across support modules (including I will begin spiking at https://github.com/rossabaker/scalaz-stream/tree/topic/lean-core. Watch for either a PR or an admission of defeat soon. :) |
The further I go toward removing scalaz-core in #322, the less appealing it becomes. It already requires a few specializations, and looks to require a few more, including interpreters for The library already supports Scalaz 7.0 and Scalaz 7.1 with git branches. My topic/cats branch also doesn't diverge much, and could be made more source compatible with syntax to reconcile differences such as A third approach would be to define our own core typeclasses and then have scataz-like modules to bridge to Scalaz, Cats, etc. The last thing I want is another monad trait in Scala. Instead of underabstracting like #322, it's overabstracting, but I'll put it on the table. |
@rossabaker @pchiusano As noble of a goal as it is to have a completely dependency-free core and to avoid "picking a winner" in the Cats vs Scalaz deathmatch, I think in this case it might be a bit of a fool's errand. As Ross said, there's a reason why we have core typeclass dependencies in the first place. Now, I can think of a couple of ways that we can make it manageable to publish a scalaz-stream artifact against both cats and scalaz, even without the current git branching scheme (which I'm not a fan of). I'm almost positive I can contort SBT into building multiple artifacts with different source directories. The majority of our sources can be in Beyond that… I'm not sure that it's possible long-term to avoid "picking a winner" in the cats vs scalaz thing. Network effect is everything for any open source project, but especially an upstream framework. Frameworks don't win on technical merits; they win on community. That's just the nature of software, because it is in fact the nature of the people who write the software. As much as I'd like to see Cats succeed, I don't mind scalaz-stream having a hard dependency on scalaz. I would certainly rather have that than have to deal with crazy contortions in dependency resolution and/or specialized function implementations to avoid said dependencies. So my preferences, in order, would be the following:
The main reason that 3 comes below 2 is because we're already hard depending on scalaz, My point is really that I don't think a dependency-free core is feasible. We can either pick a winner, or we can perform SBT magic to side-step that entire question, but I don't think we can shave our heads and withdraw from the World of the Abstracted. |
Cross building could actually be worse for the community unless each cross-built JAR puts the types in discrete packages. Otherwise, we risk incompatibilities with downstream libraries -- imagine, for instance, http4s using scalaz-stream-scalaz and scodec-stream using scalaz-stream-cats, and an app that uses both. |
I raised this point on the scalaz mailing list back when forking was proposed by Kmett. Ultimately, either Scalaz or Cats must win. Completely and utterly. If they both maintain a following but neither reaches "critical mass", then the community has the worst of all possible worlds. |
No, really, neither "must win." In fact, they are not even competing. It is ludicrous to continue suggesting so. |
Tony, tone it down please. We're having a discussion. Calling people's Anyway this is meant to be a discussion about what the scalaz stream My feeling is that if the dependency can't be broken easily I'd rather stay Michael, your point about cross builds is a good one. Honestly I can't really see myself wanting to build against multiple
|
If we factor out scalaz-core dep at an accepted price now, I still see that cost steepening over time. The more anemic core makes it harder to build higher level modules. We see this effect already in The strategy that @djspiewak lays out is not uncommon in macro projects: This extra dimension of cross building is suboptimal and frustrating, but this is where we are in early 2015. I see brilliant people bunkered down on both sides and still others straddling the fence. These strategies aren't desirable, but in this environment, I see them costing far less than a bifurcated community. |
I'm not sure that this complete win is either particularly desirable As far as the community totally adopting one or the other, the events of If there is a contest, as Paul said earlier it needs to be made on On 2 March 2015 at 08:36, Daniel Spiewak notifications@github.com wrote:
|
@rossabaker To be clear, I'm not advocating for cross building. I'd much prefer to see this library with zero dependencies and compatibility modules. |
Also to be clear, I am not advocating an exclusive or immediate switch. My branch way up in comment three is exploratory, so we downstream library authors and application developers understand and can plan to deal with the upstream situation. Besides the great schism, we have the production Scalaz 7.0 and 7.1, the imminent and binary incompatible Scalaz 7.2, and an active prototype of a source incompatible Scalaz 8.0. I would also strongly prefer zero dependencies. Ideally, similar techniques could then be used in downstream libraries like http4s and doobie and remotely, and build an interoperable, minimally opinionated stack. But if that came without costly tradeoffs, I'm not sure why we'd have type classes at all. Now, scodec-bits did it. My question is how was it achieved there, and why does it apparently hurt here? Are we overlooking useful techniques, or was that just a simpler problem? |
folks can we make a list of MUST to have TypeClases etc. in core library? I mean these that the core implementation depends on? |
All of the interpreters either need to be built against a specific type (e.g. |
The interpreters are the big one. There are a couple |
What do folks think about just specializing all the interpreters to We would definitely still need We could also if we really want just use ~> to accept On Mon, Mar 2, 2015 at 12:59 PM Daniel Spiewak notifications@github.com
|
@pchiusano +1 on specializing interpreters to Task. |
While I'm generally in favor of abstraction, so much of the useful stuff in scalaz-stream is already specialized on |
It's not just interpreters, but it is mostly
We'd also lose generic |
I think handle and partialAttempt are unnecessary. They were introduced re Channel.mapOut and Sink.toChannel, I'd like to change the representation I'd probably just make runFoldMap take the binary operation and identity as I consider Nondeterminism to be a failed experiment, so I don't mind On Mon, Mar 2, 2015 at 3:01 PM Ross A. Baker notifications@github.com
|
No thank you! We use |
@jedws The Scalaz project is motivated by very different aspirations and goals to the cats library. It boggles my mind that we are talking about "competition." A library includes a I don't mind rewriting a stream library; if only to get away from the bloody nonsense! /rant |
Specializing to |
Hang on, let's make sure we are talking about the same things here. Just to clarify, we will never specialize trait Process[F[_],A] to: trait Process[A] That would be a huge step backward. Tons of code relies on the ability to use different We are just contemplating whether the runner(s) of The reason I suspected specializing the runners to The only examples I could think of are basically things that are isomorphic to |
Well, I think for runners we can introduce type class ProcessRunner and in core library provide Task instance. Whereas others can live in scalaz/xxx bindings? i.e. def runLog(implicit runner:ProcessRunner[F,O]):F[IndexedSeq[O]] = runner.runLog
object Task {
implicit def runner[O]: ProcessRunner[Task,O] = ???
} |
Isn't On Mon, Mar 2, 2015 at 11:39 PM Pavel Chlupacek notifications@github.com
|
One might summon a ProcessRunner from a Monad and a Catchable. I admit to not having explored this technique outside a trivial REPL example: https://gist.github.com/rossabaker/bf76b4d3449636a18c12 |
@pchiusano yes, exactly. However we do not have monad + catchable in stream core, that's why we can introduce this. I don't think so we need Monad in streams core, but perhaps Catchable is reasonable TypeClass to include in streams core. |
Closing. This is done in new design. |
Hi, this is just an initial idea. I would like to explore if we can remove the dependency on scalaz. Namely this is driven by fact that I would like to have full control of concurrent primitives (like Task, Future, and perhaps Actor and Strategy) in our code and don't be dependent on release cycles of scalaz for these.
What do you think guys? I would like to see scalaz-concurrent in our code and perhaps scalaz stuff to be in separate module of scalaz-streams.
The text was updated successfully, but these errors were encountered: