Should these files be part of the kit module jars?

[martinklepsch]

I'm wondering if that would perhaps make version syncing and deployment easier?

Like kit modules could be expected to have a file in their jar kit/$module/$module.kit.edn or something that defines these transformations?

[yogthos]

I'm not sure what would be the advantage of sticking the modules in a jar. The modules are synced using git right now, and there is no deployment needed because you can just update the files in the repo and users can pull the latest changes.

[martinklepsch]

Advantages I'm seeing for including this via classpath/jars/deps:

• It couples the versioning of the module behavior to the source code of the module
  • This should make testing easier and just seems like a good idea in general?
• Discovery can happen via classpath
• Easier publication of modules (ie. no need to set up a modules repo)
  • This means its easier for others to develop and test kit modules!
• It potentially allows modules to have a concept of being "upgraded"

I'm also imagining a CLI (or REPL API) that looks like this:

# maven coord
kit add kit/sql 
# git coord
kit add https://github.com/kit-clj/kit --root libs/sql
# local
kit add ../kit/libs/sql

[martinklepsch]

FWIW I feel the same way about the documentation. Versioning documentation independently of the source just opens up the possibility of drift and makes it hard to coordinate changes between API and docs.

[yogthos]

One of the goals with the modules is to make it easy for people to make their own modules. I treat modules as templates that can be applied at runtime to inject code/resources into the project. So, it's not the same idea as libraries which are code that gets directly included in the project.

In terms of development, it's already easy to do because you just have a modules folder in the project and that's where modules are loaded from. So, if you're developing or changing a module, you just add the files locally while you're working on it. Putting files in a jar would actually add an extra step here.

And version tracking can be achieved using a field in the module metadata. However, that's less of a concern in my opinion, because once you've applied the module there's not much of a point to try and apply it again. The code also becomes part of the source the user manages, and can be changed. So it's not really easy to upgrade a module that's been injected in the project. Versioning can also be managed via git tags.

And what advantage would the proposed API have over the current one:

(kit/sync-modules)
(kit/list-modules)
(kit/install-module :kit/sql)

[martinklepsch]

Ok :) It feels a bit to me like this introduces some concepts and APIs that are new when there's already something that solves a similar purpose. I think the things you're describing would all be possible with a deps-based approach but I'm obviously also fine to agree to disagree on this one 😛

And what advantage would the proposed API have over the current one:

The main one would be that there's no need to "sync" any state and that all module behavior is defined via the artifact that you're adding. I also personally prefer the CLI interface but I think that's really a nuance.

[yogthos]

You'd still need to run some command to generate the assets specified in the artifact. Things that can be packaged up as libraries are already exposed that way via Integrant components here.

And syncing the state just ends up being replaced by having to update versions of the jars in your dependencies. Basically, in my view this adds extra steps for both packaging and consuming the artifacts without really adding a lot of tangible value in the process. :)