Exclude pod for specific tasks

[7tupel]

Hi everybody,

I've been building a simple linter for commit messages to enforce they follow the Conventional Commit Specs (on Github soon). Because I used Instaparse which is not yet compatible with Babashka I built it as a Pod. This leads to the following problem:

I would actually like to use the Pod itself to lint commit messages for the project and as such I include the pod in my projects bb.edn file like :pods {clci/pod {:path "./target/clci-0.1.1.main"}}. I also use a Babashka task to build the Pod. This leads inadvertently to a missing dependency: At the time I execute the build task for the Pod like bb build pod the binary of the Pod does not yet exist and therefore Babashka will naturally complain about the missing dependency.

Right now the quick way to circumvent this would be to comment out the parts that require the Pod when building it first time. This is very dirty and I would like to remove that obstacle. Also it would be good practice to clean all artifacts from old builds before starting a new one which would mean the binary is missing at each new build.

Is there a way to exclude the Pod as a requirement for a specific task? The build itself does not require the Pod but the tasks for testing and git hooks (implemented using Babashka) do.

Another solution I can think of would be to fetch an "old" release for the Pod to be used instead of the latest local build but that would make it more difficult to run all tests on the latest changes that only exist locally.

I would love to hear your thoughts on this an hopefully find a more elegant solution.

cheers Mo

[borkdude]

Hi @7tupel,

I agree that the bb.edn + pods approach here isn't ideal. I think the direction we want to grow towards is to have dependencies declare their preferred pod versions / manifests and you can then load those dependencies in your projects, instead of declaring pods in your bb.edn.

Would it be an idea to make a more general instaparse pod so one could use it for more purposes? I've had this idea myself for a while an your use case would be a good way to test-drive this. Then we can write a little library around (e.g. instaparse-bb) this which then loads the pod and can be used in other projects, like yours. I've done a similar thing for clj-kondo in quickdoc:
https://github.com/borkdude/quickdoc/blob/1e810ddd08ee724ff5736530a35a989d0ecdc9de/src/quickdoc/api.cljc#L9-L15

Related: an issue to improve loading pods from dependencies is here: #1291
This isn't fully fleshed out yet.

cc @cap10morgan

[7tupel]

Hi @borkdude,

I guess that would not be a bad idea. Since Instaparse only exposes a few functions it should not be much work to create a pod and a small bb library loading the pod. I'll have a look at this as afternoon project in the next days.

[borkdude]

@7tupel I've been playing around with an instaparse pod and came up with this:

https://github.com/babashka/instaparse.bb

Let me know if this is useful with your git commit library.

[7tupel]

I believe it should. I'll try switching from my custom pod experiments to use the pod you build next week.

Thanks a lot :)

[7tupel]

I tried switching to use the instaparse pod with instaparse.bb and it seems there is a bug somewhere. My best guess is the error happens during data transfer in the pod protocol when encoding/encoding the data exchanged between bb and the pod.

I created a bug report in the instaparse.bb repo.