Hi, are there maybe updates on anvil's K2 support?

# squarelibraries

[ursus]

Hi, are there maybe updates on anvil's K2 support?

[gildor]

Have you seen this?
https://github.com/square/anvil/blob/main/docs/ROADMAP.md#dagger-ksp-k2

[gildor]

For now only Zac's fork is an option, it works, we use it on prod for quite a lot of time
https://github.com/ZacSweers/anvil/blob/main/FORK.md

[gildor]

so hope to migrate on something else as soon as possible (not sure that Anvil 3.0 will happen though, probably Metro will be production ready way sooner, and it already have everything what Anvil 2 can do and much more, already no dagger and java, so it makes Anvil 3 somewhat redundant, but maybe Square have own plans for it of course)

[ursus]

yea ive seen the roadmap, its just its been month since last update again, so not sure if work is underway or not..or should migrate to metro as you say..

[mhartley]

Our team has also been waiting for any K2 support updates on anvil. We have a pretty big repo so we would be worried about spending time migrating to the anvil fork, only for base anvil to support K2 shortly after. Kind of in a holding pattern for now

[gildor]

So the roadmap is pretty clear imo, it would be no k2 or ksp support on Anvil 2

[gildor]

@mhartley I think if it's only what blocks you from K2 support, I would just go for Zac's fork, but Anvil 2 is not a long-term solution anyway.
I personally think that Metro is the way to go, but I'm still looking for what will be the official position of Anvil contributors, and I hope they just abandon Anvil 3.0 and jump on Metro too

[mhartley]

Perhaps I'm misunderstanding something, but the roadmap seems to indicate K2 support is planned for Anvil (but that those in a rush should migrate to the Anvil-KSP fork):

Introduce support for FIR and the K2 compiler...

K2 baseline support for all primary Anvil functionality...

K2 support for generating dagger factories...

Additionally, I asked about K2 support in this channel back in December and was told that's in the works:
https://kotlinlang.slack.com/archives/C5HT9AL7Q/p1737068114083049?thread_ts=1735690810.664429&cid=C5HT9AL7Q

K2 support is something the team is actively working on...

Feel free to correct me if I'm missing something though, just surprised to hear that some are saying K2 is not going to be supported for Anvil 2

[mhartley]

Also @Joel Wilcox, just wanted to check in and see if you know whether K2 support is still planned for Anvil 2. From our previous conversation I assumed that it was, but if I misunderstood that or there's been a change in plans our team can start looking into the alternatives discussed above

[ursus]

yea that what was I alluding to, roadmap says K2 should happen before anvil 3

[gildor]

ah, right, I was mixing it up with KSP, so yeah, k2 is planned to support, but again, I don't see why not just use Zac's fork now for the same reason, we use it even without Dagger-KSP

[Joel Wilcox]

Hey all! At the moment Anvil K2 development is on pause while we evaluate using Metro at Square. Metro is closely aligned with the long term goals outlined in the roadmap for Anvil 3.0 and we’re pretty excited about its potential. We’re focusing our efforts on making contributions that make the transition from Dagger2 + Anvil to Metro as smooth as possible, both for our own evaluation and anyone else who is considering it. We'll post a more official announcement on this if we decide to fully move to Metro and what that means for Anvil.

[gildor]

Those are great news Joel!
As long time adopter of Anvil, totally support it!

[Joel Wilcox]

From our previous conversation I assumed that it was, but if I misunderstood that or there's been a change in plans our team can start looking into the alternatives discussed above

No that's totally valid / not a misunderstanding 🙂. We had a split effort going on for a bit where Anvil K2 work was happening in parallel to the Metro evaluation but eventually all efforts converged on the Metro side of things -- this has happened (relatively) recently and rapidly

[mhartley]

Good to know, thanks a ton for confirming that Joel! For those open to migrating to Metro is this the doc we should follow?
https://zacsweers.github.io/metro/adoption/#option-3-full-migration

And as far as you know, is it ready for use today?

[mhartley]

Oh and given that Zac's working on Metro, can we assume that the Anvil KSP fork is no longer being worked on, and we probably shouldn't migrate to it?

[ursus]

what's missing from metro for your comfort?

[mhartley]

Oh we haven't evaluated metro yet, I'm just trying to get a lay of the land right now. If the official position is that the Anvil KSP fork is deprecated then its one less thing to compare

If the fork was an option, maybe a potential benefit would be that migration is more straightforward. We have a pretty big code base

[ursus]

i mean i tested it, everything is there and works..

[Zac Sweers]

If it’s easier to think of anvil-KSP as deprecated then sure. It works insofar as it has feature parity with anvil 2.x. PRs for issues are welcome. I’m just not actively developing it to do new things, which is not the same as deprecated imo. Deprecated to me means “stop using this, migrate off of it if you can because something is wrong with it”, and I wouldn’t say a working solution warrants that kind of urgency. You should do what’s best for you.

[mhartley]

Good point, makes sense to me. Thanks for the context Zac!

[Joel Wilcox]

For those open to migrating to Metro is this the doc we should follow?

https://zacsweers.github.io/metro/adoption/#option-3-full-migration

And as far as you know, is it ready for use today?

Yup that should be a good starting point! We're currently working with option 2 and only making strictly necessary changes e.g. using new annotations for contributed graph extensions instead of subcomponents. Functionally most things are there already -- stability/issues are going to depend a bit on what you use in your own project 😄, but issues have been getting fixed really fast

[Zac Sweers]

also if you're on Kotlin 2.2 RCs (or able to), there are preview releases of metro 0.4.0 getting published to this branch with new features and changes embracing some kotlinc fixes. Branch is going on a little longer than intended mostly because there is a critical fix in 2.2 that much of the new work relies on, but publishing regularly and will be out with 2.2's final release. Unfortunately can't backport support because 2.2 introduced context parameters into the compiler APIs, so there were a lot of backward-incompatible changes this time around heh

[ursus]

@Zac Sweers what do you think is missing from metro for it hit stable?

[Zac Sweers]

"stable" means different things to different people, not really one answer
• stable runtime API - probably pretty quick
• stable generated code - may not ever be a goal (i.e. new metro requires regenerating code)
• stable compiler API - depends on kotlinc
• stable for use - depends on your comfort level tbh. Depends on your tests, your repo, your own risk analysis, etc
It'll be stable when it's ready to be stable, by whatever metric you want to use 🙂

[ursus]

Okay I'll rephrase then 😄 Is it production ready? Are you aware of anything missing that still needs to be done?

[Zac Sweers]

Are you aware of anything missing that still needs to be done?

like... the issue tracker?

[Zac Sweers]

not to be too evasive but it does feel a little like you're just looking for someone to tell you what to do when you should be evaluating it for yourself. Doesn't matter if I say it's production-ready for me, you may have different requirements or needs. Ultimately that's your responsibility

[ursus]

Not sure why is this so offensive, there is no public roadmap available

[Zac Sweers]

It's not offensive, I'm just saying in this thread you've now asked for stable API, a public roadmap, and personal reassurance. It sounds like you want to be pretty careful about any next move (which is understandable!), which is why I'm advising you just vet your options directly rather than rely on what anyone outside of your team/codebase say anecdotally, ya know?

[gildor]

I think it's no offense to expect that no one will give any warranties yet, it's under active development
But some folks, including us, were able to migrate the whole project and considering to push it to prod

Maybe if you are not ready to actively work on DI setup, makes sense to wait and see, otherwise, you can try and report what is missing for your case and it would help to everyone

[gildor]

In terms of roadmap, there is actually a section on issue tracker with possible improvements, one of them, like support of private constructors just was implemented, and for example it's one of things which is not supported in dagger

So is feature complete depends on your project

Maybe for many projects, lack of drop-in replacement for hilt could be a blocker, but it's probably worth a separate thread to discuss

[ursus]

Okay valid points

but then, what would make it 1.0?

[Zac Sweers]

♻️ https://kotlinlang.slack.com/archives/C5HT9AL7Q/p1749252158055479?thread_ts=1748976126.715289&cid=C5HT9AL7Q