Are there plans for a Kotlin Package Manager ? sim...

# kotlin-native

[sksk]

Are there plans for a Kotlin Package Manager ? similar to SPM and Crates, something focused on simplicity, accessibility and extensible, written in native language to avoid slowness and flaws of gradle

[sksk]

my issues with gradle:

- Heavy, needs to download 200mb of tools + needs to have a JRE + compiler
- Slow, needs to warmup a deamon
- Hard to use, lot of bloat for basic operations
- Requiere plugins for uploading project somewhere

[Robert Menke]

This would be a godsend. Gradle is way too complicated.

[Dominaezzz]

No plans. I very much doubt there would be anything of the sort outside gradle/maven. Especially considering java interop will always be a thing.

[louiscad]

Well, there could be a Gradle interop @Dominaezzz

[Dominaezzz]

Yeah, I guess.

[altavir]

Gradle is quite OK. It is not 200 Mb. More importantly, it comes with dependency resolution. The plugin is just not optimized yet.

[josephivie]

The ideal, in my opinion, would be if somebody wrote some JVM libraries that made compiling Kotlin convenient, and then we started using vanilla Kotlin scripts for our builds by importing those libraries. I'm not convinced that most of Gradle's features are necessary, and perhaps a vanilla Kotlin script pulling libraries from Maven could replace it entirely.

[Dominaezzz]

Something like https://github.com/ghostbuster91/ktm ?

[gildor]

It's already possible to use Maven dependencies for script, it's not a core part of Kotlin Scripting, but I believe it will be. Also you don't need Gradle or Maven for that, so no need to create special build or distribution system

[gildor]

@sksk

needs to have a JRE

But you need JRE for Kotlin compiler, what is the point to have build system for Kotlin and don't allow to run Kotlin compiler

Bloat for basic operation

I tend to agree, but what exactly do you mean? Because most of boilerplate went from Kotlin plugin itself (which is solvable tho), not from Gradle

download 200mb

What exactly? Gradle is about 85mb, also it includes everything required for JVM development, only Kotlin plugin is required

Require plugins for uploading

It doesn't, all publishing facilities are included. If you talking about Bintray, than it's not really required, just a closer integration with Bintray

[sksk]

gradle is more than 200mb

[sksk]

even the bin one is heavy

[altavir]

It includes documentation and examples. You do not need them for build.

[altavir]

Have you ever tried to calculate how much does make weight? Or LLVM compiler toolchain? Cmake is about 15 Mb, but it does not include build tool itself, only a configurtator.

[sksk]

that's my point, it is bloated by default, this mindset is bad, but anyways, size isn't the main concern, the problem is it is slow, and it is complex to setup

[altavir]

Gradle? Complex to setup? Are we talking about the same gradle?

[altavir]

I really do not get your point. It is really not large compared to other build tools. Also, are you going to code in VIM? If not, the build tool size is tiny compared to other tools like IDEA. Also the artifact repository usually weights few GB.

[sksk]

yes it is complex to setup, and all the attempts made to simplify it results in a slow and heavy "build" tool, wich it already was by nature(JVM), because gradle itself doesn't know about kotlin at all, that should speak for itself already

[sksk]

if that is not bloat for you i don't know what it is, new gradle project created from intellij, try to figure out how to run it just by looking

[altavir]

What do you meant by "does not know"? Gradle includes kotlin compiler. If you mean that you need to install a plugin? It is plugin based. And basically it is a one line. Current MPP builds a large because the plugin is universal and has a lot of handles. It is quite easy to create a specialized plugin which will require a single line to use. I've done it for our projects. And plugin includes specialized deploy routine. Like this: https://github.com/mipt-npm/dataforge-core/blob/dev/dataforge-meta/build.gradle.kts

Gradle has some problems, and I am going to write an article about it, but slowness, heaviness and inflexibility are not those problems.

[altavir]

How the hell should it know it is not a library and which entry point to use?

[altavir]

Use gradle-init with application template if you want to get application

[altavir]

It is a question of flexible tool versus I-am-too-lazy-to-read-documentation tool. And in fact you can do the later with gradle by creating a custom plugin, which could be initiated with one line. Then you deploy it to central repository, and voila, you get minimal configuration. The thing is my minimal configuration won't be the same as your minimal configuration. Have you ever tried to deploy something with CMake?

[sksk]

CMake is even worse, my point is UX is horrible, have you ever tried to deploy a crate with Rust ? dead simple

[altavir]

As for you troubles, try adding application to the list of plugins, it will work.

[sksk]

i know how to do it, i wanted to try to show you how a new user would react

[altavir]

You can create a beginner plugin for new user if you want. There is no reason to create a new build system if you do not like the default plugin configuration.

[gildor]

gradle is more than 200mb

No, it is not. You showing wrappers dir, which may contain multiple versions and unzipped files.
You said "download", but it's not download, just check size of bin version of Gradle (with no sources,l and samples):
https://services.gradle.org/distributions/

Also, I agree Gradle distribution may be smaller, quite many plugins will be removed from default distribution in 6.0, but I see some contradiction in you complains, that you don't want to download big tool, but also want everything included, I would prefer small as possible distribution and all plugins downloadable, even core Gradle plugins, but honestly it's not a big problem imo, because it covers the main Gradle use cases (build, test and publishing)

[gildor]

if that is not bloat for you i don't know what it is

I completely agree, and it's exactly what I wrote above, all those boilerplate is coming from Kotlin Plugin, and it's quite easy to solve actually, it isn't problem of Gradle itself
But to be fair, almost everything on this config is optional, for example Java plugin, jvm target version, group, version
But it can be better if Kotlin Plugin will be more opinionated (which I believe right approach)

[spierce7]

I think there are too many important things that need to be focused on before things like this. I also think a lot of the confusion with Gradle is remedied with kotlin script gradle. I'd also prefer to see heavier investment into other build systems like bazel or buck rather than re-inventing the wheel (again).

I will say that one of the weaknesses that I see with maven dependencies is just how ridiculously complicated it is to release them, and get them on maven central / jcenter. One of the beautiful things about package management on other systems is how stupid easy it is to release your own library.

[gildor]

other build systems like bazel or buck rather than re-inventing the wheel

You can use Kotlin with bazel and buck, but it’s painful, because usage of buck or bazel is pain itself and they are not designed to be easy to use, they design top be fast in multi-module projects. So I don’t think that Kotlin team should invest into it, it’s definitely not a choice for simple project

[gildor]

But In general I completely agree with you, inventing own build system will not solve any problem, it will bring more, better to invest to existing tooling, there is a plenty of ways to improve what we have. Even Gradle tooling requires a lot of work, there are many things that can be improved and improve them way easier than implement it from scratch

[gildor]

And yes, +100 to publishing.
It’s quite complex problem tho,
Java publishing is quite fine, still require a couple of not so obvious (but pretty simple) configs
It’s a lot worse on Android, but soon it should be finally fixed and Android plugin will provide publishing component
Kotlin also fine, but would be nice to have ready to use tasks/components for publishing Kotlin sources and KDoc
Kotlin Multiplatform another problem, because it require a lot of new facilities and would be cool to have support of NPM publishing

All those problems tho can be solved on side of Kotlin Gradle Plugin, just should be more opionated and easy to use, and I also think it will be a lot easier to fix it than inventing the wheel

[hhariri]

Yes. There are plans and we have something in the works. Stay tuned.

[Bogdan]

@hhariri Is JB working on a new build system?

[hhariri]

I’m talking about package discoverability and management, not build system. Which I believe was the original question.

[altavir]

Thank gods. I started to freak out

[louiscad]

Sound like something like pub.dart

[sksk]

my question was about both, gradle really needs to be replaced, it is heavy and slow

[gildor]

What is "heavy"? Slow for what, comparing with what and in which use cases.
It's just very naive claim

[spierce7]

I ❤️ Gradle... it's fantastic, and it's also gotten pretty fast in the past few years. You may be confusing certain slow/heavy gradle plugins with Gradle. i.e. the Android Gradle plugin is very heavy and slow.

[josephivie]

I'm now looking very seriously into the possibilities, using things like kscript and skate to do Kotlin-only project definitions. I'm interested in people's thoughts and ideas:
https://github.com/UnknownJoe796/kbuild

[spierce7]

More power to you, but build systems are the way things are moving. If people didn’t use gradle, they’d gravitate towards something like buck or bazel. They are simple enough for simple things, and offer very complex scalable growth to complicated things.

Kotlin-script gradle aims to make things more understandable, adding code completion, and allowing Gradle programming in Kotlin.

[josephivie]

@spierce7 Goodness, I'm bad at writing. I see how you interpreted it that way, but it's Kotlin used as a build system. It's literally a Kotlin library for compiling projects. You use it from the standalone Kotlin runner of your choice, like skate or kscript. Yeah, build systems are pretty necessary once you start making more complicated projects - this just makes the 'system' part Kotlin.

[spierce7]

That’s basically the same goal is kotlin-script-gradle.

[spierce7]

The primary difference is that kotlin-script-gradle has a dedicated team, several years of work from a team and the community, and can leverage tons of the community provided build plugins that already exist, along with lots of documentation. I struggle to see the value of a project like this, especially with gradle being pretty simple, and the speed and performance that gradle brings to the table. It’s also officially supported by the Kotlin team.

[josephivie]

Gradle Kotlin script gradle uses a special dedicated runner - Gradle itself - and is still weighed down by years of Groovy untyped-ness. This is literally just a library that could be included in any normal Java project. Also, having written Gradle plugins and managed complicated multiplatform projects, I respectfully disagree that Gradle is simple. Gradle is complicated, and tracking the execution path of it and figuring out the effects of plugins is tricky. I'm not worried about the slowness of Gradle; I'm worried about the sheer number of API declarations. I want simplification and proper types. I want less.

[louiscad]

@josephivie The motivation of simplifying is a good one. I wonder how you'll be able to support all Kotlin multiplatform features (including klibs, compiled libraries…) and have IDEA recognize it with dependencies though.

[josephivie]

@louiscad I've actually been looking into stuff like that - it turns out IntelliJ is just creating .iml and .xml files in the IDEA folder for you when you're using Gradle. In fact, there's an option you can turn on in the settings of IntelliJ to put those files into the project with your stuff, so I even have a fairly-detailed and reasonably simple-to-get reference for the format.
Remember, this is in Kotlin with Maven! I can simply pull in the Maven libraries on most things. For example, I've pulled in the embedded Kotlin compiler and now I have the original, fully typed interface that the Kotlin team themselves created for my use.

[louiscad]

Oh, interesting! Nice to know the experiment road for that is not barred. I'm watching your repository, hoping one can learn from it, or maybe see it become a viable Gradle alternative that is simpler to understand, adapt to and troubleshoot.

[sksk]

i'd be all in with gradle if it was:
- Faster
- Less complicated
- Lighter

[sksk]

any other stuff that requires JIT to be "ok" shouldn't be proposed imo