search

arrow-kt / arrow

Λrrow - Functional companion to Kotlin's Standard Library
http://arrow-kt.io
Other
6.13k stars 442 forks source link

Discussion around the Gradle setup #3423

Open CLOVIS-AI opened 4 months ago

CLOVIS-AI commented 4 months ago

Hi! @nomisRev asked for help with the Gradle setup of Arrow, and I'm interested in helping. However, I'm not too familiar with the existing setup nor what you expect, so I'd like to discuss it a bit first.

My understanding is the main problems at the moment are centered around Maven Central and duplication in build.gradle.kts files? For Maven Central publication, I'm not an expert, but I have migrated all my projects to this plugin and haven't had any issues since. In particular, this plugin allows publishing an artifact in multiple steps (e.g. to build the JVM/JS platforms on one machine, the iOS platforms on another machine, and then combine everything into Nexus).

Now, for the config duplication;

The first and most important question is whether you want to share configuration between multiple Arrow repositories. I see there is https://github.com/arrow-kt/arrow-gradle-config, but I haven't looked much into it yet. Sharing config between repositories by publishing convention plugins is the most effective solution, but comes at the cost of quite a lot of flexibility (on each change, you have to edit the conventions, publish them, bump the version in the downstream repository).

If each repository is different enough, then they may each have their own convention plugins to share internally. However, this is a bit slower because Gradle isn't that performant on up-to-date checks. It also increases the time-to-index when opening the project for the first time, but I don't know how much you care about this.

Looking at the current state, I guess you're aiming for a hybrid approach; how do you decide what goes into arrow-gradle-config or not?

nomisRev commented 4 months ago

Hey @CLOVIS-AI,

The Arrow project is very old, and it has gone through a lot... Over the years we've moved more, and more to "vanilla" configuration, and were able to get rid of our custom tooling in favor of new 1st party tooling (like KotlinX Knit).

The Arrow Gradle Config came to live only because we were stuck with publishing KMP with 1.0. Since we didn't know what to do we turned to the community, and Arrow Gradle Config was born but was quickly abandoned. So personally I am in favor of getting rid of Arrow Gradle Config, because the maintenance costs are way too high, and it's constantly been behind since its inception.

Requirements:

@CLOVIS-AI, to be completely honest I don't think a lot of us have a strong opinion about this. My goal is to move towards what is recommended, and/or most used, in Kotlin. This will improve ease of contributions, readability, and maintenance. So feel free to make a counter proposal, or suggest any other changes to our Gradle configuration.

Thank you @CLOVIS-AI 🙌

CLOVIS-AI commented 3 months ago

From what I gather, the final objective is to have as much as possible in this repository, and avoid using the Arrow Gradle Config repo altogether?

If so, what's your plan when you want to create spin-off repositories?

Sorry for the long time to answer, KotlinConf was wild!

nomisRev commented 3 months ago

Sorry for the long time to answer, KotlinConf was wild!

No worries, no time pressure for OSS but KotlinConf really was wild 😂

If so, what's your plan when you want to create spin-off repositories?

To be honest I was thinking we'd just have a little bit of duplication. The formatter is a non-issue, it's a 1 liner in 99% of the cases. So that only leaves configuring the targets, is it worth it keeping that in a separate repo? All spin-off repositories seem to have slightly different target requirements since they build on top of specific stuff.

CLOVIS-AI commented 2 weeks ago

Would it be accurate to say that you wish to stop using https://github.com/arrow-kt/arrow-gradle-config and have everything needed be in this repository instead?

It would make working on this repository much more flexible, but it may slow down the builds a little. Though as far as I can see, you're not using the build cache nor the configuration cache, which will both noticeably speed up builds.