Support distributing pods as manifest libraries #1390
Conversation
Still need to make this work w/ :local/root pod libs and in uberscripts
|
Relies on these changes to the pods submodule: babashka/pods#58 |
|
I documented the various moving parts of all this in doc/pod-libraries.md |
|
Looking into the failing tests now |
|
PR pushed to this branch with corresponding PR in pods: https://github.com/babashka/babashka/tree/cap10morgan-feature/manifest-libraries |
| base-path (.replace ns-str "." "/") | ||
| manifest-paths (loop [ns (str/split ns-str #"\.") | ||
| paths []] | ||
| (let [path (str/join "/" (conj ns "pod-manifest.edn")) |
There was a problem hiding this comment.
Perhaps we can make paths be calculated lazily and use concat below.
There was a problem hiding this comment.
Yeah, probably. Not sure if it would be worth it or not since the number of these generated per namespace should be pretty small (number of dot-separated ns components minus one). But I'd happy to implement it if you think it's worth it.
|
What if I wanted to expose clj-kondo.core in my library for clj via normal code but for bb via the pod, so people can use the same namespace? Then the manifest has to live in /clj_kondo/pod-manifest.edn - but what if there are more libs that have the clj_kondo prefix? It feels a little bit brittle. What I expected instead (in previous discussion I tried to convey this) is that we would have clj_kondo/core.pod.edn for example, so it becomes unambiguous. Yes, you would have to insert the manifest potentially n times, each time for every namespace, but to circumvent that, you could support a redirection in the .pod.edn to clj_kondo/clj_kondo.pod.edn or so which then contains the complete manifest. |
|
Another thing to consider: how would people force pre-downloading of pods in this situation for packaging for lambdas? |
|
An illustrating example of what I'm saying in the first comment: There I'd love to just be able to require |
Yeah, that's a good question. I'll have to explore that a little. My first thought is to do something similar to uberscripts and run all of the top-level |
Please answer the following questions and leave the below in as part of your PR.
I have read the developer documentation.
This PR corresponds to an issue with a clear problem statement. Automatically download pods for tasks that are defined in a dependency #1291 is probably the most applicable, but the scope of this is broader than what the issue describes. Happy to create a new issue if desired.
This PR contains a test to prevent against future regressions. Still TODO. I'll work on that next if this approach looks more or less OK.
I have updated the CHANGELOG.md file with a description of the addressed issue.