Fork me on GitHub

@davids to expand on what @alexbay stated with my own understanding; Many of the boot tasks place files in what it refers to as “Temp Directories”; The task “target” places it in the final location which is considered “write-only” and unlike the Temp is not anonymous to the user.


does anyone have a good setup for boot+clojure+scala ? I want to have a "scala" directory, with *.scala files -- that are auto recompiled when any file changes -- and to be able to easily call the scala files from clojure scala does NOT need to call clojure, I only need clojure to call scala (this is for some performance-matters numeric code)


I managed to create the jar but it doesn't contain any source files.


okay, I figured it out, if I add my source folder to :resource-paths then it adds it to the jar file. If I understand correctly this because in this scenario the clojure files don't need any compilation.


Could you tell me what is the best way to include build-only sources in a project? I am thinking of extracting some tasks to clojure files under a 'scripts' directory. I don't want them included in the output jar file.


Would :source-paths not work for that case? The sift built-in task may also be useful:


@sinistral no, if I add to :source-paths then it will try to compile the scripts as well, which I don't want, and will also fail because they depend on boot.


Opinions please : I’m implementing a service similar to jarkeeper - mainly as an exercise in aws lambda, but also because jarkeeper seems to have gone dark. And so I’m supporting Leiningen by reading the project.clj as edn and then extracting the :dependencies from there. For boot based projects is the same strategy reasonable? Can I safely assume the form containing set-env! has what I need?


I read your convo below with @U04V70XH6 and I think there's an important point worth considering -- boot is more flexible than leiningen with its notion of dependencies. a leiningen project has a canonical list of dependencies, i.e. it makes sense to refer to "the project's dependencies" as a single entity boot, on the other hand, gives you set-env! and merge-env!, which allow you to mutate the dependencies you're working with ad hoc as you need them. it's common to see individual boot tasks with their own ad hoc dependencies, source paths, resource paths, etc. so in that sense, i don't think it actually makes sense to "extract the dependencies" from a boot project


i think the closest you could get to that would be to run a particular boot task and, while the task is running, inspect the dependencies in the env programmatically. that may or may not be insanity, though


Yes, I considered that, but I’m really reluctant to run arbitrary user code in my service. If I were doing this for commercial gain, I would look for a suitable way to sandbox the execution and prevent malicious behavior. As this is just a side project, I’m not sure I can justify the effort.


I think you'll get a good percentage of Boot projects, just with the basic act of looking for set-env! and merge-env! and :dependencies. There will just be some that you trip up on.


Thanks Sean, exactly my thought. If I had a product manager I would have her/him go assess what that percentage is 🙂


(Right now, however, I’m fidding with joplin and dynamodb.)


@sinistral what I managed to do is to just (load-file "scripts/whatever.clj") into the build file


Has anyone been able to get boot-cljs-test working with :chrome-based karma testing? I've run afoul of PhantomJS not supporting ES6, but when switching to karma it simply doesn't run any tests. It does work for a lein doo project rendered by chestnut, but not for a boot-cljs-test project rendered by tenzing.


@gonewest818 Re: Boot -- we keep all our dependencies in EDN files and we keep "pinned" versions in a .properties file, and functions in Boot files to read the EDN and patch the versions and then add them to :dependencies. And one Boot file may produce different dependencies for different combinations of tasks.


TL;DR: No, you can't just read a build.boot and expect to find dependencies.


And with tools.deps we should expect to find dependencies in external files more often I think.


Also, re: set-env! -- at a minimum you'd need to read merge-env! forms as well.


as I feared. I’m not enthusiastic about executing foreign code in the service (as in, boot show -d) due to the potential for accidental or intentionally malicious behavior.


Well, and even boot show -d doesn't take into account the tasks that might add to the environment, and of course boot some-task show -d would potentially run all sorts of "foreign code" as you say...


...because a Boot file is "just code" there's no easy way to identify dependencies, unfortunately.


I know we're not the only ones using Boot with external dependency files. Not sure about the format of other folks. We're thinking about switching to the new deps.edn format if we can make it applicable...


(I suspect most Boot projects have dependencies in build.boot directly tho' -- you just can't rely on it)


Understood. Okay, well it being a side project I’ll mull this over a bit. My gut says start by supporting set-env! and merge-env! as the “mvp” and then look at external dependency files if I can detect a de facto convergence in the community. As an analogy: with python I’d be fine starting with requirements.txt