Does/will Amper support taking a github repository...
# kotlin-toolchain
d
Does/will Amper support taking a github repository url as dependency? Golang as example has this feature
j
It's not out of the realm of possibility, but it has to be carefully considered. There might be a bunch of implications. In the JVM world, it's much more common to share published binaries instead of recompiling on every machine. That's the power of portable bytecode. In the Go world (and native in general), sharing binaries is much more cumbersome because they have to be created for every platform, so depending on sources and recompiling the world on every machine is more typical.
But I'm interested now, in which way do you think it would help? Is it to make it more convenient on the library author side?
d
Oh I see, you have a good point, thanks for replying in details. I have a Golang-lover friend who always mentions features that Go has over JVM, and that’s why it came to my mind, however it depends how you sell it, rather than actual value
gopher heart 1
For me the benefit would be the idea of “single source of truth”. Let me explain, for example you see a github dependency, you want to check the entire code, you copy paste the URL and you are right in the github repository Whereas with maven-central dependency style, you have to google the artifact name, match it with a github/gitlab/butbucket repository, and sometimes companies don’t have matching artifacts for their repo code etc Then it comes deployment of a particular lib, usually pushing something to the git repo and creating the new tag would result in a new release by itself, no need to double push to maven-repository, it results in a clearer workflow However GitHub style dependencies have their own pitfalls as well
j
Let me explain, for example you see a github dependency, you want to check the entire code, you copy paste the URL and you are right in the github repository.
Whereas with maven-central dependency style, you have to google the artifact name, match it with a github/gitlab/butbucket repository, and sometimes companies don’t have matching artifacts for their repo code etc
If the project is open-source, the maven dependencies normally come with a
-sources
jar as well, so you don't need to go anywhere, you can navigate to the sources right from your IDE (which already downloaded them). So on the consumer side, it wouldn't be an improvement IMO.
Then it comes deployment of a particular lib, usually pushing something to the git repo and creating the new tag would result in a new release by itself, no need to double push to maven-repository, it results in a clearer workflow
Yeah, publishing to Maven Central is definitely a pain point on the publisher side, I agree. So indeed it would make things easier for library authors. That said, it also means that the same code has to be compiled as many times as there are builds with this dependency, as opposed to once at publication time, which is a bit sad (and not very eco-friendly 😄). So yeah it is an interesting idea to improve the experience of library authors. At the moment, we believe we can already improve a lot the experience of library authors by providing built-in support for Maven Central publication, and possibly signature setup etc. On Sonatype side they already made some improvements to the process. But as I said, it's not out of the picture. It was actually brought up in recent discussions in the team (in the context of sharing Amper plugins via a github repo).
d
Btw regarding the problem of "...on JVM is more common to share published binaries instead of recompiling on every machine" , if it's the only problem that stops effectively using github as a dependency provider then maybe there is a solution to that How about using the Tag/Release Assets section and include the pre-generated jar there (instead of publishing it to maven-central) ? https://stackoverflow.com/questions/37786539/how-to-upload-github-asset-file-using-curl Then if you know the repo, tag, and the binary name (should be standardized) it could work ?
There was also a discussion somewhere about publishing multiplatform libraries format problem, I do not remember exactly the words, but the idea was that maybe it's "non ethical" to publish iOS KMP lib to maven-central or something like this, so investigation new opportunities is a plus in the KMP context, though I could mistake here