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

yeah

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

yep

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

yeah

or perhaps if you require foo.bar.baz 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

yeah

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