Fork me on GitHub
#babashka-sci-dev
<
2022-04-04
>
cap10morgan17:04:43

@borkdude there may already be a good way to do this, but if not, what do you think about adding a download-pods (or similar) subcommand for when you just want to pre-download your pods? i.e. bb download-pods reads your :pods from bb.edn, downloads them to ~/.babashka/pods, and exits. could also run describe on them and pre-cache that too I suppose (which is what I think will happen unless we take steps to prevent it for some reason).

cap10morgan17:04:07

or maybe prep-pods

cap10morgan17:04:38

I ran into a need for it (packaging pods as aws lambda layers) so I got it working locally. happy to put up a PR if you think it'd be generally useful

borkdude18:04:05

Doesn't that already happen when you run bb --version for example?

borkdude18:04:18

or any random other command

cap10morgan18:04:35

Perhaps! Haven't tried it yet. But I will.

cap10morgan19:04:37

yeah, bb --version works for now. might want an explicit command at some point though. I could imagine recommending that people use bb --version for this and then later deciding to optimize that out there since it doesn't need to do all of that work to print its version.

borkdude19:04:19

does deps.edn have a specific command to download deps? I thought they do it the same way: deps are always downloaded as an effect

borkdude19:04:00

either way bb -e nil should do the trick as well. adding more subcommands: I want to hold off until that's really necessary

borkdude19:04:03

as we already have a lot

borkdude19:04:41

bb -e '"download-pods"' ;)

borkdude19:04:18

or bb '(do :download-pods)'

cap10morgan19:04:02

tools.deps used to do it the same way, then they added an explicit command for it

cap10morgan19:04:36

namely clojure -P

cap10morgan19:04:53

documented as: Prepare deps - download libs, cache classpath, but don't exec

borkdude19:04:16

fair enough, we might add prepare which downloads both deps and pods

borkdude19:04:32

and just does -e nil under the hood or so

cap10morgan19:04:35

but they still also download them on-demand as we should too

cap10morgan19:04:43

yeah, that makes sense

cap10morgan19:04:21

I can work up a PR for that (as I think it's already done save a small name change)

borkdude20:04:02

Have you tested it? :)

cap10morgan20:04:22

yes, it works

cap10morgan20:04:29

for deps and pods

borkdude20:04:31

a-w-e-s-o-m-e!

😁 1
cap10morgan20:04:23

CI failure looks intermittent, but let me know if not

borkdude19:04:43

@cap10morgan I had another idea. We could allow manifests to be directly fetched from https. So we could have:

{:pods {foo/bar {:manifest ""}}}

borkdude19:04:39

not sure if it's a good idea ;)

borkdude19:04:29

but it would take care of the "multiple repositories" in a more flexible way

borkdude20:04:53

wow, on neil main branch:

$ ./neil dep search cheshire
:lib cheshire/cheshire :version 5.10.2
:lib cambium/cambium.codec-cheshire :version 1.0.0
:lib com.vgeshel/cheshire :version 5.3.1.2
:lib metosin/muuntaja-cheshire :version 0.6.8
:lib fuziontech/ring-json-params :version 0.2.0
:lib org.clojars.doo/cheshire :version 2.2.3
:lib dsabanin/cheshire :version 5.1.2-SNAPSHOT
:lib sbtourist/cheshire :version 2.0.3_1
:lib cn.leancloud/cheshire :version 5.11.1-SNAPSHOT
:lib gorillalabs/muuntaja-cheshire :version 0.8.0
:lib com.github.youkale/cheshire :version 5.10.2-SNAPSHOT
:lib com.clojars.olimsaidov/cheshire :version 5.10.0
:lib org.clojars.vljosa/cheshire :version 5.5.1-SNAPSHOT
:lib io.xapix/cheshire :version 5.8.2-SNAPSHOT
:lib org.clojars.artmsh/cheshire :version 5.8.1-SNAPSHOT
:lib org.clojars.dlg/cheshire :version 5.8.2-SNAPSHOT
cc @teodorlu

borkdude20:04:29

published new version of neil