-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should these files be part of the kit module jars? #22
Comments
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. |
Advantages I'm seeing for including this via classpath/jars/deps:
I'm also imagining a CLI (or REPL API) that looks like this:
|
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. |
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) |
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 😛
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. |
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. :) |
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?The text was updated successfully, but these errors were encountered: