hey all... any plans to de-couple the release of a...

# arrow-contributors

[stojan]

hey all... any plans to de-couple the release of arrow-optics (especially the ksp compiler plugin) from the rest of arrow and do more frequent releases? asking because ksp is tied to specific compiler version.... and that is a direction some projects (e.g. compose) are taking

[simon.vergauwen]

Hey Stojan,
That is actually a great idea. It's something we've discussed but nothing was planned.
Most of us are currently also super busy 😕

Is this something we could entice you to look into? 😜

cc\\ @Alejandro Serrano Mena

[Alejandro Serrano Mena]

we had some preliminary thoughts at some point about how to manage the complexity of different arrow versions and different compiler versions, which affect not only arrow-optics, but also arrow-analysis

[Alejandro Serrano Mena]

unfortunately, we didn’t manage to get a good technical solution for generating and uploading all the artifacts

[simon.vergauwen]

Is KSP doing this all manually?

[stojan]

ah... true forgot about analysis

I'm currently interested in introducing optics at work, and this was one of my concerns....

compiler plugins are tied to specific kotlin version... arrow itself is not a big problem...

so ideally whenever a new kotlin version is released, we would get a new version of the optics/analysis compiler plugins that work with the latest kotlin release and lates arrow version at the time.... it doesn't have to be tested with all arrow versions..

e.g. compose keeps this compatibility map for the compose compiler: https://developer.android.com/jetpack/androidx/releases/compose-kotlin#pre-release_kotlin_compatibility

[raulraja]

It may be possible to do this with KSP because the API is not breaking on each release of KSP but it will be harder with Arrow Analysis until FIR is stable.

[stojan]

is that because optics uses KSP and Analysis doesn't?

[raulraja]

yes, analysis currently depends on an AST which is built with the descriptor API and depends on the Expression checker parts of it.
I'm not sure KSP has all we need for analysis. Can KSP read and codegen over expression or just declaration signatures? If it can read calls and expression bodies it may be possible to rewrite analysis or provide a KSP impl for https://github.com/arrow-kt/arrow-analysis/blob/main/analysis/common/src/main/kotl[…]sis/phases/analysis/solver/ast/

[raulraja]

our current plan with analysis is wait for K2 FIR to come stable because it's supposed to work directly with the IDE

[stojan]

I'm not familiar with the internal workings on KSP, but AFIK it only offers what's possible with APT

[raulraja]

the kind of checks we do in analysis are best shown in the IDE as it's mostly oriented to reporting errors and KSP on itself has the same issues as KAPT or other codegen, you need a full compile to typecheck properly on the IDE

[raulraja]

FIR get's rid of that because the compiler plugin can hook up to the IDE analysis loop as you type on the editor

[Alejandro Serrano Mena]

Afaik KSP may only generate code, and it doesn't give access to the body, so it doesn't work for us