Fork me on GitHub

by the way, I worked up a proof of concept for that idea of making pod wrapper libraries be nothing more than manifest.edn resources and putting all of the handling logic in babashka itself. it seemed to work, I just need to clean it up and get it into a PR.


yes, I'm excited about that!


I also want to think / discuss a little more about how best to structure and distribute these from a pod author perspective. this adds another "moving part" to an already complex system.


there might be an opportunity for helper libs and/or project templates here


one thought I kind of go back and forth on: we could allow people to package up every platform's binary into the maven-hosted library along w/ the manifest.edn file if they cared more about simplicity than space efficiency.


sort of an uberpod 🙂


yeah, let's just start with the manifest.edn as part of a library


I think that's already a big enough leap forward


I think deploying 100mb binaries to clojars isn't what we want


just thinking about converting libs to pods or converting existing pods to this new approach and all the different things you have to do


but if we can start w/ documenting how to add the manifest.edn resource file to a new / existing pod project, how to build a JAR w/ just that in it using tools.deps and lein, and then how to deploy those to clojars, that's probably a good start


the manifest in lib thing is just a way to get version resolution managed by tools deps and to not have to use the centralized registry, I think for now


since babashka would be scanning for manifest.edn files across the whole classpath under this approach, do you think we should require that they be named e.g. pod-manifest.edn or bb-manifest.edn or similar to avoid false positives w/ other resources?


I'd like to prevent a scan if we can since we need to do this every time bb starts up, so maybe we can come up with something so a full scan can be prevented


or perhaps we could cache stuff or so


I think we'd need a way to flag those libs as pods to avoid a scan


maybe we should also just measure first what a scan costs typically on a long classpath


or perhaps if you require we can have foo/bar/baz.edn which is a pod manifest or something that indicates to look somewhere else


IIRC the caching we already have in place still works here


the number of namespaces for pods are usually quite limited so having a special resolver for pod stuff per namespace might be ok


perhaps just an indirection to the manifest


so baz.pods.edn or so would have look in my resources/META-INF/babashka-pods/my_lib/manifest.edn