https://kotlinlang.org logo
Channels
Powered by
#feed
Title
# feed
s

sam

08/06/2019, 2:07 PM
d

dave08

08/06/2019, 3:17 PM
It looks very nice, but is there a separate artifact for Arrow support? So that those that don't use it, will not end up having a big dependency they don't use...
s

sam

08/06/2019, 3:31 PM
It’s built using arrow itself, so it would be pulled in regardless
d

dave08

08/06/2019, 3:32 PM
Fine, but in Gradle, you could probably limit it, since otherwise people will end up with tons of extra classes...
s

sam

08/06/2019, 3:35 PM
limit it how ?
l

LeoColman

08/06/2019, 3:35 PM
api
vs 
implementation
probably
d

dave08

08/06/2019, 3:35 PM
right!
s

sam

08/06/2019, 3:38 PM
But you need it on the classpath for hoplite to work
so either way it’s getting put into your final jar
d

dave08

08/06/2019, 3:39 PM
The idea is that people won't understand `Monad`s etc... and will think that they are part of the standard library or something... even if the classes are in the jar, the IDE's autocomplete won't get flooded...
s

sam

08/06/2019, 3:40 PM
oh ok
but if I use implementation will it still be added to your build transitivity ?
d

dave08

08/06/2019, 3:41 PM
Probably, only compileOnly will just use the dep in compile time... but then I'm no Gradle expert...
s

sam

08/06/2019, 3:46 PM
I’m not so sure because ultimately it ends up as a pom in maven central
and maven has no concept of this
i

ilya.gorbunov

08/06/2019, 6:53 PM
@sam pom dependencies can have 
runtime
scope, so it should be possible to represent the same concept in maven.
s

sam

08/06/2019, 6:55 PM
runtime means that it’s required at runtime but not at compilation time.
The library uses Arrow to represent errors internally as 
Validated
along with other uses. So it’s needed to both compile, and to run. It’s not possible to ship this without arrow as you need arrow to run it but… I’d be open to copying the source files into the project itself and removing the dependency. It would only be 3 or 4.
👍🏼 1
i

ilya.gorbunov

08/06/2019, 9:01 PM
runtime means that it’s required at runtime but not at compilation time.
I believe that's how Gradle's 
implementation
dependency configuration should be mapped onto the Maven dependency scope. Maven pom produced from Gradle build describes how to consume the library, and not how to build it.
s

sam

08/06/2019, 9:08 PM
If 
implementation
compiles with the dependency and then puts runtime into the pom, when someone adds it to their build it will throw a class not found exception if they don’t also add the required classes. So what’s the advantage? They ultimately need to add the dependency anyway.
i

ilya.gorbunov

08/06/2019, 9:16 PM
Ok, if you expose Arrow types in your public API, then you definitely depend on it as 
api
. We're talking about the situation when you don't expose them, which seems not to be the case here.
j

jdiaz

08/06/2019, 9:18 PM
I really need a marketing course lol. I wish I could do thsi for my library 😄
s

sam

08/06/2019, 9:20 PM
Even if they’re not in the public api, but used by the internal code, you still need the dependency, so I think either way it’s going to be 
api
. I’d be open to shading the dependencies though as it’s only a few files. That’s probably a better solution than requiring everyone to have arrow if that’s not what they want.
l

LeoColman

08/06/2019, 9:43 PM
I don't really get all the anger towards bringing a dependency in... So many libraries bring so much inside them, and we usually never even see them. "They'll think Monad is in the STDLib" that doesn't happen for any class that comes bundled in any library I have ever used
When creating a UberJar or an APK, unused classes are removed anyway
People will never think "Oh, they added this class to the STDLIB". I just tested the monad example because I didn't even know I had Arrow on my classpath
s

sam

08/06/2019, 9:47 PM
I tend to agree, but I am also sensitive to the fact people may not want a dependency that does kind of “pollute” the namespace (for want of a better term)
l

LeoColman

08/06/2019, 9:48 PM
It does pollute the name space, but we don't usually complain about it
s

sam

08/06/2019, 9:49 PM
But it’s clear why some people may not want that.
l

LeoColman

08/06/2019, 9:49 PM
I agree, and I understand the pollution issue. Mainly in Arrow, that usually has everything on the 
Any
namespace
If it's trivial to shadow the dependency or split the artifacts, you should go for it
But if it's not that easy, Maybe there are ways around it
j

jdiaz

08/06/2019, 9:51 PM
I tend to think that a library as core as a configuration library should not bring many libraries as it might be used by small programs. Then you can have all the extras that you want, but not fore the "core".
👍🏼 2
l

LeoColman

08/06/2019, 9:52 PM
That's a good point
s

sam

08/06/2019, 9:55 PM
Yeah I agree 100%. I’ll move the arrow 
Decoder
instances to hoplite-arrow, and then shade the files the library uses. Thanks to @jdiaz @dave08 @ilya.gorbunov @LeoColman for the feedback
👍🏼 1
b

bdawg.io

08/06/2019, 11:48 PM
IIRC when they presented the idea of 
api
vs 
implementation
back at KotlinConf 2017 was implementation was meant to remove autocompletion of transitive dependencies that were purely 
implementation
details whereas 
api
was for dependencies exposed by your public API
l

LeoColman

08/06/2019, 11:50 PM
Is that implemented?
g

gildor

08/07/2019, 2:55 AM
Yes, it’s supported by Gradle Tooling, you have only classes exposed as API, not Implementation, this is the whole point of different dependency configuraions
So many libraries bring so much inside them, and we usually never even see them
You do, and even worse, you sometimes use it, but only because some library leaked implementation details, it;’s the same as use public everywhere
s

sam

08/07/2019, 5:55 AM
I don't understand this at all. If I have a class that I use internally in an API, lets say 
com.google.wibble.Foo
whether it's 
implementation
or 
api
, that class must be present on the classpath at runtime. So what exactly is this difference giving me ?
g

gildor

08/07/2019, 5:58 AM
DIfference is that user of your library can use this com.google.wibble.Foo too now, so essentially it because API of your library. Now you replaced it with 
com.acme.wibble.Bar
in new version and it broke everyone who used it With 
implementation
user of your library knows nothing about 
com.google.wibble.Foo
, it’s runtime dependency
s

sam

08/07/2019, 5:59 AM
What is a runtime dependency ?
It's on the classpath regardless
g

gildor

08/07/2019, 6:00 AM
it means that it can be used on runtime, but cannot be used during compilation of your client library
s

sam

08/07/2019, 6:00 AM
Ok, so this is some gradle magic that enforces this ?
g

gildor

08/07/2019, 6:00 AM
s

sam

08/07/2019, 6:00 AM
Ok so whn this library is deployed to maven central, like 99% of libraries, that magic is going away
g

gildor

08/07/2019, 6:00 AM
Parially Gradle, partially Maven POM
s

sam

08/07/2019, 6:01 AM
as Maven has no concept of it
g

gildor

08/07/2019, 6:01 AM
like 99% of libraries, that magic is going away
No
s

sam

08/07/2019, 6:01 AM
Ok explain please 🙂
g

gildor

08/07/2019, 6:02 AM
Maven also have concept of scopes for dependencies and it encoded in POM ffile
s

sam

08/07/2019, 6:02 AM
runtime, compile, etc
none of which are "use only for this project"
g

gildor

08/07/2019, 6:03 AM
no, this is exactly what is runtime in POM
This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
s

sam

08/07/2019, 6:03 AM
runtime This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
g

gildor

08/07/2019, 6:03 AM
so?
s

sam

08/07/2019, 6:04 AM
lets work through it
So I release a library. It has a single class, 
class Foo { private val wibble = com.other.Wibble() }
Wibble is in a dependency of my project
if I set the dependency to runtime in the pom of my project, when someone adds it
g

gildor

08/07/2019, 6:04 AM
if you add a library which has 
runtime
transitive dependency, user of this library cannot use this dependency
s

sam

08/07/2019, 6:04 AM
but it's needed at runtime !
And maven will not add it !
g

gildor

08/07/2019, 6:04 AM
yes!
will add
s

sam

08/07/2019, 6:05 AM
Will it
g

gildor

08/07/2019, 6:05 AM
Yes
s

sam

08/07/2019, 6:05 AM
So a runtime dependency in my pom, means maven will add it to the path for execution but not to compile other projects
And you're sure that such a runtime dependency is also carried through transitivity to dependent projects
g

gildor

08/07/2019, 6:06 AM
yes
s

sam

08/07/2019, 6:07 AM
So I'm wrong 🙂
g

gildor

08/07/2019, 6:12 AM
Also yes. I use this for a couple years for JVM and Android starting from Gradle 3.4 where it was introduced I recommend to read java-library plugin documentation it has nice explanations about this feature: https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation
s

sam

08/07/2019, 6:12 AM
I've used maven for 15 years. I guess I've still got stuff to learn.
g

gildor

08/07/2019, 6:12 AM
But want to add that you right, if you expose any type from your dependency in your public API you have to use `api`/`compilation` configurations
s

sam

08/07/2019, 6:13 AM
I've set the arrow deps and others to implementation now https://github.com/sksamuel/hoplite/commit/e6c59cc5950ad051dac49590358e94371664ecab
g

gildor

08/07/2019, 6:14 AM
Why do you use compile and api together? you need only 
api
, which mostly the same as 
compile
s

sam

08/07/2019, 6:19 AM
because like you say isn't api the same as compile
g

gildor

08/07/2019, 6:50 AM
yes, the same. This is why compile will be eventually deprecated (it’s already “soft” deprecated)
2 Views
Powered by