https://kotlinlang.org logo
Join Slack
Powered by
Are there other ways to distribute K/N libs withou...
# kotlin-native
k
Are there other ways to distribute K/N libs without uploading to maven? From my understanding Jitpack only accepts JVM's. Are you able to add a dependency via git by any chance? gitRepository?
e
Jitpack doesn't limit builds to JVM only, but sometimes it has problems distributing the various variants that KMP uses and it only has Linux builders so you can't build for all platforms
why not upload to Maven? it is easy to create your own repository: if you can host static content somewhere, you can host a Maven repo (although Gradle requires that HTTP HEAD is supported)
Gradle also supports https://docs.gradle.org/current/userguide/declaring_repositories.html S3 and GCS out of the box, if you're using either of those already
k
You should (probably) be OK with GitHub repos. We’ve also used S3 for internal stuff. You need to manage access, obviously. GitHub is somewhat easier for that because it just uses GitHub access.
e
yes, if you're already using GitHub, and don't mind not having anonymous access, https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-gradle-registry works. it does have a couple downsides though: strongly immutable (you can't ever fix any uploads) and no anonymous access (all users must have a GitHub access token)
k
Yeah, the anonymous access part is rough. I was surprised about that for open source. I’m mixed on re-uploads. I like it in principle (not changing dependencies), but it can be frustrating for dev builds. Also, you can just delete and reupload, which is more “annoyingly-mutable” than “immutable”, but for internal stuff, GitHub is pretty good.
e
if you're putting dev builds on there, you might need something like https://github.com/actions/delete-package-versions to keep your storage usage bounded, and if a (public) package exceeds 5000 downloads it can't be deleted. but I suppose that is unlikely to be reached for a dev build
k
Interesting. I did some back-of-envelope calculations on the dev builds we’re thinking of and size wasn’t a huge issue, but it’ll grow forever, and some teams do interesting things at scale 🙂
I also assume if you’re at that kind of scale, the extra monthly from GitHub isn’t going to matter much, and/or you have a dev ops team who wants to use something else anyway.
k
As for the question of "Why not maven" Mainly because I've never done it and I've heard people talk about their horror stories with it (getting things uploaded or waiting ages for it to even be uploaded and finalised) I also use Kotlin for hobby and I'm not a dev in my normal day to day job so I'm not 100% aware of most things so apologies for that
e
uploading to Maven Central does take some effort to set up, that is true. but publishing to a local directory as a Maven repository then sharing that directory is super easy
k
Would you have any links on guide how to do it by any chance?
v
I came across reposilite yesterday while looking for something similar. I still need to check it out how it works but from a first look at their docs it looks like a relatively simple solution to self-host a maven/gradle repo with S3 storage support. https://reposilite.com/
l
I’ve been seeing occasional incorrect 409 conflicts when publishing to GitHub Package Repository. I’ve reached out to support, and they are aware of the problem. Because it’s very sporadic (seems to be every few hundred artifact publishes now), they can’t find the cause.
k
We were getting that with KMMBridge when a publish failed mid-run, but after the file was pushed (would fail on next run). That was because the file already existed. Seeing them spontaneously isn’t good news, but thanks for the heads up. We pushed fix for our particular problem, but if I saw another 409 I’d probably pull my hair out at this point.
l
The GitHub support rep sent me a document that shows how to remove an artifact using a REST API. I can see if I can dig up the doc. The goal was to detect an incorrect 409 conflict and write a script that would delete that whole release and start over. I never got around to writing the script, since the issue became much less frequent.
Our project has 60 artifacts or so. It got really tiring when it would fail early, and I had to run the individual publish tasks for the rest of the artifacts.
k
For our issue, we just kind of handled it upstream. We’re auto-incrementing dev versions, and using tags for that, so we have a pending release tag, which gets factored into calculating the next release version. So, say you pushed 1.2.17, there would be a tag flagging that (but with a prefix so as not to confuse SPM, etc), then if that failed, the next build would do 1.2.18, etc. Long story. Essentially, if anything is wrong with a build for iOS, and you’re trying to publish CocoaPods, it’ll fail, but the artifact needs to exist, so it was chicken/egg, and we run a growing pile of integration tests for the library itself. We’d often run into issues where the integration test would fail, and then you have to open every repo and remove the blocking artifact. Yada yada, it was rough. Not saying our solution is a great idea either, but needs must.
60 artifacts, huh?
l
Several modules (ui, business logic, bindings to a library, models, app, K/N bindings to a C library and a JNI layer for JVM, etc) that each support at least android and the 3 iOS targets. Several also supported desktop platforms. It adds up.
8 Views
Open in Slack
PreviousNext
Powered by