Is there any thought to move `amper` inside the `k...
# amper
h
Is there any thought to move
amper
inside the
kotlin
gradle plugin binary under a flag? I don't know if that makes any sense, but I'm just trying to figure out how to minimize the number of required plugins.
Thinking more about it, and for now it does make sense during this experimentation phase to keep it separate. If it became more officially supported, I suppose it could become part of the primary plugin.
a
No such immediate plans; to move fast we try to avoid any dependency for now.
👍 1
d
Do you want to address the pain of remembering that you have to apply one more plugin? (and also remembering its coordinates, version, etc.) Or is there something else as well? For example, if there were an IDE action like “Add Amper to the current Gradle project”, would that address the pain points you were thinking about?
h
I was just thinking that
amper
is kotlin specific and it is another plugin to add. I totally get why it's separate for now, but if this became a part of the ecosystem, it seems like it'd just be something you enable or disable and not something you'd have to pull in separately. I think having to know about all the different dependencies and plugins you have to pull in is a struggle for newer folks.
This was just an idea/thought. I'm not sold on this, but it seemed like it could be a way to approach this.
👌 1
d
No, definitely agree with your point here! It’s kinda same for me with this “foojay” plugin for Gradle toolchains — like, I’m already using Gradle, why I need to add some additional dependencies to benefit from a Gradle feature.
👍 1
h
@dsavvinov - My comment I just left in this other thread addresses the point of why it's nice to have one plugin that orchestrates adding additional plugins -> https://kotlinlang.slack.com/archives/C062WG3A7T8/p1706801355629919?thread_ts=1706723406.109109&cid=C062WG3A7T8