Is there a permanent place for okio snapshots? I r...

# squarelibraries

[Paul Woitaschek]

Is there a permanent place for okio snapshots?
I referenced com.squareup.okio:okio-multiplatform:2.10.0-20201202.152951-29 but now our ci starts failing because that snapshot got removed. I need to use the snapshot because I’m targeting watchosArm32 which is not present in 2.9 and I want reproducible builds

[mbonnin]

Could you reference com.squareup.okio:okio-multiplatform:2.10.0-SNAPSHOT instead?

[mbonnin]

That should stay until the version moves to 2.11.0

[mbonnin]

But it won't be reproducible

[jessewilson]

I think we should cut a release

[jessewilson]

It's rare we add this much without one

[jessewilson]

Files is weird because it needs some time to incubate

[Paul Woitaschek]

That would certainly make my life easier ^^

[Paul Woitaschek]

Btw that okio multi platform stuff is really nice. We’ve written a solution where we serialize to protobuf and then have our own simple protocol where we use okio to build delimited messages. Thats used by ios / watchos / android. The outcome is so hardcore fast and small 👍

[Paul Woitaschek]

And I really did not want to write that byte fiddling for ios

[Paul Woitaschek]

Our only issue was that GzipSink is only available on jvm

[mbonnin]

You could add a RequiresOptIn annotation to the top-level classes to signal that some APIs are still incubating?

[Paul Woitaschek]

@jessewilson
What's the reason there is okio and okio-multiplatform? Shouldnt it be possible to merge okio-multiplatform into okio as gradle figures the jvm resolution out itself?

[Paul Woitaschek]

Also the project site doesnt mention anything about the okio-multiplatform artifact at all which made it really complicated to discover for me:
https://square.github.io/okio/

[mbonnin]

I think coroutines do such a merge with the JVM jars and metadata .module file in the same coordinates : https://repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-coroutines-core/1.4.2/

[Paul Woitaschek]

It's actually quite easy with the multiplatform plugin:
https://kotlinlang.org/docs/reference/mpp-publish-lib.html

[jessewilson]

Quite possibly! The thing we really need is backwards compatibility for JVM users

[jessewilson]

So whatever artifact identifier they've been using should keep working

[russhwolf]

I know I’ve seen a youtrack ticket or github issue where JB talked about their strategy for doing that, but I’m having trouble finding it now

[mbonnin]

Maybe this ? https://kotlinlang.org/docs/reference/whatsnew14.html#specifying-dependencies-only-once

[russhwolf]

No, it was specific to how the kotlinx libs were migrating their metadata dependencies from kotlinx-libname-native to kotlinx-libname artifacts while maintaining compatibility with people using kotlinx-libname as a JVM artifact

[russhwolf]

Looking again, I think this was this issue I was remembering https://youtrack.jetbrains.com/issue/KT-39184

And reading it again, I think the issue JB was having is different than what Jesse is worried about, but I don't have a great appreciation for the compatibility subtleties here so I can't tell whether or not there's anything helpful.