search

Deraen / sass4clj

SASS compiler for Clj, Lein and Boot, using Libsass Java wrapper
70 stars 16 forks source link

Specifying dependencies in POM for Boot plugin #23

Closed danielcompton closed 3 years ago

danielcompton commented 6 years ago

The Boot plugin dynamically adds the sass4clj dependency at runtime, when the plugin is called.

https://github.com/Deraen/sass4clj/blob/240c099c4fddf7b541cce1642967ec044cba260f/boot-sass/src/deraen/boot_sass.clj#L72

This is a problem in CI, because my dependencies have already been downloaded before I run my SASS build. Is it possible to add the sass4clj dependency to the POM for the Boot and Leiningen plugins? I know version handling stuff like this can be tricky, so I wanted to check if my idea made sense.

https://github.com/Deraen/sass4clj/blob/240c099c4fddf7b541cce1642967ec044cba260f/build.boot#L76

Deraen commented 6 years ago

Idea with both Boot plugins (using pods) and Leiningen plugins (loading dependencies in another JVM process), is that it prevents dependency clashes with your project dependencies and plugin dependencies. Sass4clj uses cheshire, jsass etc. and including having them (and their dependencies) as transitive dependencies would affect your project even when you are not using Sass4clj. So no, I don't think this would be good idea.

Deraen commented 6 years ago

Btw. is this about CircleCI? In v2 you can manage yourself at which point the dependencies are cached, so you can cache even the deps that are loaded only during the build.

danielcompton commented 6 years ago

Idea with both Boot plugins (using pods)

Gotcha, this makes sense, I forgot/didn't consider Boot's pods.

Leiningen plugins (loading dependencies in another JVM process)

Here I don't think it is really necessary to dynamically add the dependency if you need it in the Leiningen JVM. If you want it in the application's JVM then dynamically loading is an (the only?) option.

Is this about CircleCI v2?

Yeah I noticed it more after upgrading to v2. I know I could cache the dependencies again after the build, but it feels dirty.

Anyway, on the Boot side this is a larger issue than just this plugin. I think it could be useful for Boot to distinguish between which dependency resolution and dependencies being added to the Classpath.

Deraen commented 6 years ago

Here I don't think it is really necessary to dynamically add the dependency if you need it in the Leiningen JVM. If you want it in the application's JVM then dynamically loading is an (the only?) option.

Many (lein) plugins have to run with application classpath, e.g. sass4clj and less4clj do this because the application classpath might contain dependencies that provide stylesheets, like webjars bootstrap and such.

Yeah I noticed it more after upgrading to v2. I know I could cache the dependencies again after the build, but it feels dirty.

I think it is completely fine to cache deps after all the tests etc. have run. I used to run all tests on deps step with Circle v1.

Anyway, on the Boot side this is a larger issue than just this plugin. I think it could be useful for Boot to distinguish between which dependency resolution and dependencies being added to the Classpath.

Yeah. We had issue about this (https://github.com/boot-clj/boot/issues/282) but I closed it after I found workaround for Circle. I think there isn't yet issue open about the larger problem. And anyway, it would be huge change to change how Boot tasks can create pods dynamically. Tasks would need some kind of way to declare their dependencies beforehand or something.