typelevel/catbird

Birds and cats together

catbird

This project provides Cats type class instances (and other useful Cats-related stuff) for various Twitter Open Source Scala projects.

It currently includes the following:

• Type class instances for Future, Var, and Try (including Monad or MonadError, Semigroup, and equality)
• Category and profunctor instances for Service
• A Rerunnable type that wraps Future but provides semantics more like Cats Effect's IO

These are reasonably well-tested (thanks to Discipline).

Community

People are expected to follow the Scala Code of Conduct on GitHub and in any other project channels.

License

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this software except in compliance with the License.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

catbird's Issues

Consider changing versioning scheme

Now that Twitter Util is on a <year>.<month>.<patch> scheme it might make sense for catbird to follow suit. The one downside is that (at least until Cats hits 1.0) we may still want to introduce breaking changes out of sync with the Util / Finagle release cycle, but this seems reasonably easy to work around.

Publishing broken

https://github.com/typelevel/catbird/runs/6393978143

It's failing on the MiMa check, because I guess I didn't really set that up properly. Once a versioning/bincompat strategy is decided it'll be clearer what to do.

ContextShift instance

It would be useful to have a ContextShift instance as a generic alternative to FuturePool (eg for blocking io). I think that evalOn would fulfil this role and should behave essentially as FuturePool does now.

I'm not sure what shift should do though. It seems like the main relevant use case would be to improve fairness on cpu-bound work running on a small pool of threads. It could do this by:

• calling Scheduler.flush() - doesn't switch threads and I think is dangerous to do a lot because it adds stack frames
• constructing the ContextShift instance with a thread pool intended for this purpose and having shift switch between threads on that pool - but it seems wrong to force the user to provide this pool if all they want to do is use evalOn

Consider updating packaging and coordinates?

As discussed here, this repository is now in the Typelevel organization. It's not strictly necessary to move the project from io.catbird to org.typelevel, but I think it'd be a good idea. This would involve two changes:

• Change the publishing coordinates from io.catbird to org.typelevel. This is easy, simplifies publishing rights, and imposes a very small burden on users (just updating the dependency in their build config).
• Change the packaging from io.catbird.* to org.typelevel.catbird.*. This is more of a burden on users, but is a completely mechanical change.

We could technically just do the first but not the second, but I also think it'd be good to stay consistent, and I'd like to get rid of the io domain at some point (for various reasons).

Additional maintainer

@bpholt has graciously stepped forward to continue maintaining Catbird. It's always good to have a second maintainer, when either the person or the project gets busy. Volunteers?

Release Cadence

There have been a handful of upstream releases from Twitter. Is there anything blocking a release for 21.8.0?

Going forward, would it be possible to automatically release upon updates from Twitter, assuming everything passes in CI?

Conflicts with com.twitter.bijection.twitter_util.UtilBijections._?

I have a file that uses com.twitter.bijection.twitter_util.UtilBijections._ with com.twitter.bijection.Conversion.asMethod extensively to convert from com.twitter.util.Future to scala.concurrent.Future.

I'm introducing cats' EitherT into that file to be used with com.twitter.util.Futures and need a cats.Functor[com.twitter.util.Future] to do that so I added import io.catbird.util._.

Unfortunately it seems to conflict with bijection somehow, giving me errors like this on each use of the bijection conversion:

                       [error] /Users/omer/code/sigma-monorepo/src/jvm/com/thesigma/server/graphql/schema/main/SigmaSchema.scala:2206: missing argument list for method as in trait Ops
                       [error] Unapplied methods are only converted to functions when a function type is expected.
                       [error] You can make this conversion explicit by writing `as _` or `as(_)` instead of `as`.
                       [error]           ).as[ScalaFuture[Connection[OrgActivity]]]

ScalaFuture here is scala.concurrent.Future and as is being called on something with type com.twitter.util.Future[Connection[OrgActivity]].

I don't see another as defined anywhere in the catbird source so have no clue where to start trying to fix this. Any suggestions? I can create a small repo demonstrating the issue if it's helpful/necessary. Thanks!

Switch to Typelevel steward?

I think Scala steward is updating this repo under its old location. We can remove it and add it to the Typelevel steward instead.

https://github.com/VirtusLab/scala-steward-repos/blob/695a916678fad5aa3eedc97796c67c5bfc114051/repos-github.md?plain=1#L1374

https://github.com/typelevel/steward/

Add a test that fails without the fix in #45

I've confirmed that #45 makes the iteratee.io tests pass, but it would be nice to have a test here that would fail without the fix so that we can be more confident that this doesn't regress again.

Decide when to drop 2.11 support

The Cats and cats-effect 2.0.0 releases are almost six months old. We have 2.1 releases for both, and will have Cats 2.2.0 soon, and none of these support Scala 2.11. Finch is likely to drop Scala 2.11 before long (e.g.).

There's no particular reason that's come up for us to drop 2.11 here yet, but as soon as it becomes a burden I'm ready to let it go. If someone really needs it, please let us know.

Add Mergify to build

Add sbt-typelevel-mergify to the build to help with maintenance. If a maintainer approves a Scala Steward PR, Mergify can automatically merge it for us.

Suggestion: make clear that instances calling Await are unsafe

There are a few uses of Await in typeclass instances provided by util: Eq and Comonad for Future and Rerunnable.

I suspect the Eq instances are only intended for testing, in which case they could just be moved into test. I'm not sure what the Comonad instances are for at all - I can't envisage a use for them personally.

So my initial suggestion is:

• move the Eq instances into test
• move the Comonad instances into an unsafe or maybe alleycats subpackage with some docs to make it clear to the user what they're getting into (alternative option: just remove them)

I would be happy to do the gruntwork if a change is agreed on.

cats.Applicative[com.twitter.util.Future]

How do you import the implicit Applicative for the twitter future? I've got:

import io.catbird.util._

Support a cats.Parallel to support parallel operations on Rerunnable

Currently, I don't see a method to take several Rerunnables and run them in parallel (like IO.Par allows in cats-effect).

Even a method on the companion: def parSequence[F[_]: Traverse, A](as: F[Rerunnable[A]]): Rerunnable[F[A]] would be very nice to have.

Support ConcurrentEffect on Rerunnable

see: https://github.com/twitter/util/blob/develop/util-core/src/main/scala/com/twitter/util/Future.scala#L1496

I think this is possible, but a bit of work. Could be useful for a few cases I can think of at Stripe.

LiftIO Instances for Future and Rerunnable

Would LiftIO instances for Future and Rerunnable be welcomed? I couldn't find laws for LiftIO but these rough implementations seemed to work after some limited testing I did.

implicit val rerunnableLiftIO: LiftIO[Rerunnable] = new LiftIO[Rerunnable] {
  override def liftIO[A](ioa: IO[A]): Rerunnable[A] =
    Rerunnable.fromFuture(LiftIO[Future].liftIO(ioa))
}

implicit val futureLiftIO: LiftIO[Future] = new LiftIO[Future] {
  override def liftIO[A](ioa: IO[A]): Future[A] = {
    val p = Promise[A]

    ioa.unsafeRunAsync {
      case Left(ex) => p.setException(ex)
      case Right(a) => p.setValue(a)
    }

    p
  }
}

Finagle Upgrade

Are there any plans for upgrading Finagle to the most recent version: 22.3.0 ?
I can potentially look into taking on the changes if I can get support in getting the PR reviewed/merged/released

@bpholt tagging you since you seem to be active on the repo

Publish for Scala 2.13.x please

Publish for Scala 2.13.x please. Its a dependency of Eff

Support Scala 2.13

There are two reasons I'm reluctant to do this at the moment.

The first is that Cats doesn't yet have non-milestone, non-RC releases for 2.13. For a number of my other projects I've been tracking the pre-final Cats 2.0.0 releases, but this is a library that I'm not personally using at the moment, and that I don't think carries all that much value as an example for testing things out, so I didn't really want to start publishing a bunch of milestones and RCs. Now Cats 2.0.0 is likely only a week or so away, so I think it definitely makes sense to wait.

The second reason is that while the latest release of Twitter Util (19.8.1) introduced support for Scala 2.13 a couple of weeks ago, Finagle doesn't support 2.13 yet. I hate maintaining builds where submodules have different cross-versions, so my plan was to wait for Finagle.

That said, if someone wants to open a PR updating to Cats 2.0.0-RC2 and setting up the build so that cross-building and publishing works cleanly, I'd be happy to review it and run the release. Otherwise this will wait for Cats 2.0.0 and Finagle.