Arrow: Artifact reorganization - 2nd iteration

[JorgeCastilloPrz]

What's required

After first iteration we'd be ready to complete the final approach on which Maven artifacts we want to provide.

After a chat with @raulraja, the plan is: (Let's take arrow-core as an example)

• arrow-core: contains both arrow-core-data and arrow-core-typeclasses, and the extensions defined between them.
• arrow-core-data: Just the data.
• arrow-core-typeclasses: Just the typeclasses.

That will give users the chance to pick every module as a whole, just data or typeclasses separately, so better granularity when needed.

We'd repeat that for all the artifacts where it makes sense, like arrow-extras, arrow-free, arrow-effects, arrow-recursion...

[JorgeCastilloPrz]

We've got this in our roadmap but we're always open for help if someone wants to take it. Sounds like a doable task for people wanting to contribute.

[1Jajen1]

While we are at it, should we also sort out the dependencies for each project? Right now they look very much copy-pasted all across, with many things having useless deps or using dependencies transiently from other deps. This would require going through each build.gradle and minimizing deps for each project and also replacing the deprecated compile keyword with other api or implementation for whatever we'd want there. I have done this in an outdated branch once, its a few hours fighting the compiler but I think it's worth it, especially if the plan still is to move away from a mono-repo. If this does not really intersect this issue I can create a new one...

[JorgeCastilloPrz]

I can see the need for that but can't find it strongly related or required to complete this task. I'd personally suggest creating an issue and addressing it separately.

But feel like it's a good idea and should definitely be done if that's the case.

[mkobit]

Ok just for my confusion going from 0.8.2 to 0.9.0 - arrow-core for 0.9.0 doesn't actually exist, right? I was looking at https://arrow-kt.io/docs/quickstart/libraries/ and trying to bump some versions and was confused, but it looks like it is going to be reintroduced as part of this ticket.

[pakoito]

arrow-core-data for now, yes -.-

[JorgeCastilloPrz]

I think @i-walker is taking this one. Am I right? How are you doing with that?

[i-walker]

Yes, all WIP.

[i-walker]

We will move the data types first and then later on the packages:
https://github.com/arrow-kt/arrow/pull/1458#issuecomment-496022046

[nomisRev]

@JorgeCastilloPrz I edited your message a bit. The extensions should be defined in the top module, and the seperation should be between data and typeclasses.

Import the most "top-level" module (arrow-core) brings in data types (arrow-core-data) & typeclasses (arrow-core-typeclesses) + it defines the relationship between them (currently the extensions modules).

[JorgeCastilloPrz]

Thanks. I think the description was not updated after our meeting where we discussed this. Does that remove the chance to export extensions separately also? that was another requirement we had in our discussion (I think), so you could import extensions, data, typeclasses, or all together using the root

[nomisRev]

When you depend on extensions you are already implicitly depend on the typeclasses & the data types. So we'd just create more overhead for ourselves by creating a fourth module, which would be an alias for the top-most one.

[i-walker]

These were the PR's
https://github.com/arrow-kt/arrow/pull/1496
https://github.com/arrow-kt/arrow/pull/1492
https://github.com/arrow-kt/arrow/pull/1495
https://github.com/arrow-kt/arrow/pull/1488
https://github.com/arrow-kt/arrow/pull/1481

[pakoito]

We're missing MonadFilter, TraverseFilter and MonadCombine back in core.