babashka-sci-dev

cap10morgan 2022-09-21T19:15:07.035589Z

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.

borkdude 2022-09-21T19:15:21.825089Z

yes, I'm excited about that!

cap10morgan 2022-09-21T19:15:28.108739Z

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.

cap10morgan 2022-09-21T19:15:48.105679Z

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

cap10morgan 2022-09-21T19:18:08.909449Z

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.

cap10morgan 2022-09-21T19:18:40.759649Z

sort of an uberpod 🙂

borkdude 2022-09-21T19:19:22.244789Z

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

borkdude 2022-09-21T19:19:31.876179Z

I think that's already a big enough leap forward

borkdude 2022-09-21T19:20:05.895609Z

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

cap10morgan 2022-09-21T19:20:10.733879Z

yeah

cap10morgan 2022-09-21T19:20:34.919469Z

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

cap10morgan 2022-09-21T19:21:52.362369Z

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

borkdude 2022-09-21T19:22:02.951369Z

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

cap10morgan 2022-09-21T19:22:11.469699Z

yep

👍 1
cap10morgan 2022-09-21T19:27:17.130699Z

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?

borkdude 2022-09-21T19:28:57.797079Z

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

borkdude 2022-09-21T19:29:11.159009Z

or perhaps we could cache stuff or so

cap10morgan 2022-09-21T19:30:11.697319Z

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

borkdude 2022-09-21T19:32:09.957489Z

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

cap10morgan 2022-09-21T19:32:17.328509Z

yeah

borkdude 2022-09-21T19:33:10.758779Z

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

🤔 1
cap10morgan 2022-09-21T19:33:29.246339Z

IIRC the caching we already have in place still works here

borkdude 2022-09-21T19:34:09.783639Z

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

borkdude 2022-09-21T19:34:30.079609Z

perhaps just an indirection to the manifest

cap10morgan 2022-09-21T19:34:40.436449Z

yeah

borkdude 2022-09-21T19:35:02.963599Z

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