Just coming from a demo meeting about Amper. I've ...

# amper

[David Herman]

Just coming from a demo meeting about Amper. I've been doing a lot of work recently in Gradle, and it might be useful for someone on the team to reach out to me as I have questions / feedback about what Amper extensibility might look like. Feel free to DM me and we can set up a meeting later. (Very excited about Amper btw!)

[amakeev]

David, would you prefer to have a DM conversation or would starting the discussion here be fine for you?

[David Herman]

Oh I was thinking the DM would be for setting up a 1:1 meeting where I talked about stuff stream of consciousness style.

[David Herman]

Something where maybe I could share my screen and show some code while I chat

[David Herman]

Of course we can talk here as well, but I think it might get messy

[David Herman]

Since no one has reached out, I'll drop some high level thoughts. Up to the team if they want to reach out for more.

Note that I'm assuming Amper extensibility implies some form of a task graph written in some Kotlin code behind (not the yaml config file), which is driving some of these thoughts. That may never be in the cards, at which point ignore these :)

• Amper logic should push developers to create an api part and an impl part. I have been bitten several times in Gradle now because one plugin pulls in dep version A and another wants to use dep version B and they're both living in the same classpath
• With Gradle, it is sometimes not clear what part of a task is run at configuration time and what runs later. I think if Amper revisits this sort of API, they should probably find a way to be a lot clearer about it. Here's a random example of a task in my code that unless you put printlns in places, you might be surprised about what happens at config time and what happens at exec time.
• Gradle extension objects cannot differentiate between "null" and "not set yet" (since they use Java's type system and not Kotlin's). It would be nice if Amper was able to fix this.
• It's very easy to write Gradle code which not only works but has tons of examples online showing it that way, except it's the legacy way and you're not supposed to use it anymore, because it will break caching / task avoidance for example. It would be nice if Amper could be designed from the ground up to force people to think of everything as chaining, so there's only one way to do things.
◦ In other words, it might have been nicer if Gradle was stricter about EVERYTHING being a provider and there weren't direct queries -- and that you could only query a provider in specific contexts. (I played around with this concept a bit in a toy library I worked on a few years ago. The syntax might even be cleaner if we could use Kotlin context recievers)
◦ I once got a bug report on my plugin because another plugin did a direct get too soon, which caused my code to be evaluated too early as a side effect, making it look like I was the one that crashed the user's build logic. If you weren't savvy about the newer Gradle lazy APIs, it would have been very hard to realize their code was even wrong.
• Please please please document Amper better than Gradle docs do.
◦ Gradle docs feel like so many partial dives into complex topics that aren't driven by concrete examples but instead by small snippets that are often missing context. And then while you're still scratching your head, they've moved onto the next section.
• Gradle discourages sharing output directories, because it messes up caching, but it was a long time before someone pointed that out to me. Perhaps Amper could take a page from Bazel/Blaze and have every task output to its own unique sandbox (although this makes heavy use of symbolic links which may still be a non-starter on Windows). Alternately, it would be really nice if there were easy ways to see a task's inputs and outputs inside the IDE.
Apologies if none of these apply to the future direction that the team wants to take Amper. But if any of these ideas sound interesting, feel free to give me a ping anytime.

[amakeev]

Thanks David, these all a very valid points. You did a great job summarizing them!
Overall, I believe we are on the same page, on what the extensibility should and shouldn’t be like. Once we start designing the extensibility (we are not there yet), we’ll surely refer to this list. Once we have something to share, it will be a perfect time to discuss it it greater details.

[David Herman]

This fledgling project just came across my radar:
https://github.com/GradleUp/gratatouille

I think it is an approach that would solve pretty much every single bullet point I mentioned here.

Basically, instead of writing gradle code, you write constrained Kotlin code which gets converted to gradle code by a KSP plugin.