Fork me on GitHub
#boot
<
2016-08-10
>
richiardiandrea00:08:32

so I have a weird configuration a little, and I need to specify :compiler-options {:asset-path ...} in the cljs.edn files (I have three js files) and plus this path can change based on the if I am running dev or staging

richiardiandrea00:08:24

so I would really like to ask if there is something like :asset-host so that I don't have to specify the name of the .out folder

richiardiandrea00:08:56

or what are the alternatives (if any) to intercept and rewrite the cljs.edn files

richiardiandrea00:08:05

based on the build type

tianshu08:08:08

how can I sift js files to specific path after cljs task? I've tried something like this:

(deftask dist []
  (comp (cljs :optimizations :advanced)
        (garden :styles-var 'cms.styles/screen :vendors ["webkit"] :auto-prefix #{:animation})
        (sift :move {#"main.css$" "../src/main/webapp/statics/css/sns/cms_editor.css"
                     #"editor.js$" "../src/main/webapp/statics/js/sns/cms_editor.js"})))

martinklepsch09:08:31

@doglooksgood: sift only works within the fileset. not possible to move files outside of it (you can write a task that does http://java.io stuff)

martinklepsch09:08:31

the src/main/webapp/ directory, does that belong to the same project?

tianshu09:08:44

It not belong to the same project.

tianshu09:08:06

maybe i should move with a shell script.

tianshu09:08:18

thanks very much!

martinklepsch09:08:35

yeah, either move via http://clojure.java.io or use target and a shell script 🙂

Jon13:08:47

I got some problems fetching 2.6.0, network is slow in China but I tried more than 10 times but still failed.

Jon13:08:55

it there anything I can try?

alandipert13:08:00

@jiyinyiyong: you could checkout the git repo and do git checkout 2.6.0 and then follow instructions from https://github.com/boot-clj/boot#hacking-boot

alandipert13:08:11

that will install 2.6.0 to your local ~/.m2

alandipert13:08:08

^^ alternate download of boot.jar, will still talk to clojars when you run

Jon13:08:10

where should I put this boot.jar ?

alandipert13:08:35

rename to boot and chmod u+x boot to make executable, then put on path

alandipert13:08:37

err, hold on, that's wrong

Jon13:08:17

I'm also trying brew update, also slow here...

alandipert13:08:10

if you have the repo cloned i think your best bet is to build locally

alandipert13:08:44

that process does download stuff, but from maven central, not github

alandipert13:08:05

mvn == maven

alandipert13:08:09

brew install maven should do it

vikeri14:08:07

I have the following setup that I wonder if boot could accomodate. As I understand it boot is generally not creating files which I like. But can I somehow pass the temporary file location to a node script and run the node script before terminating the boot task?

micha14:08:35

@vikeri: totally, that's the core pattern

micha14:08:15

isolate the build steps that assume they can run wild on the filesystem to the temp dirs encapsulated by a task

vikeri14:08:56

Hmmm, being a bit of a beginner in boot, do you have any examples?

micha14:08:08

the general idea is like this

micha14:08:29

your build pipeline consists of a number of steps, each contributing to the final artifacts

micha14:08:51

the input end of the pipeline is your project files, :source-paths, :resource-paths etc

micha14:08:57

those are also on the classpath

micha14:08:02

and in the fileset

micha14:08:32

when you use jvm tools in your build steps, like the java compiler for example, they all expect to find their inputs on the classpath

micha14:08:51

and they write their outputs to some configurable directory as files

micha14:08:32

the downside of this normally is that they assume that they can write to the globally shared filesystem

micha14:08:46

which is not great because now your tools can step on each other's toes

micha14:08:11

and the filesystem is basically shared mutable state with no controls

micha14:08:37

boot tasks address this by carefully controlling what the java compiler sees as input, and controlling where it can write its output

micha14:08:02

so the javac task looks in the fileset for files that need to be compiled

micha14:08:44

it passes the paths to these files (files in the fileset also exist in temp directories on the filesystem, and are on the classpath)

micha14:08:12

so it passes the paths to java compiler and configures the compiler to emit class files into a temp directory created by the task itself

micha14:08:30

that temp directory is not known by any other task, and is not on the classpath

micha14:08:37

it's a private direcotry basically

micha14:08:14

after the java compiler has compiled the java source into class files, and written those files to the temp dir, the task adds the contents of the temp dir to the fileset it was given

micha14:08:23

that creates a new immutable fileset object

micha14:08:54

the task then calls boot.core/commit! on the newly created fileset object, which syncs its state with the actual filesystem underlying the fileset

micha14:08:04

that will put the new class files on the classpath etc.

micha14:08:13

depending on how you add them to the fileset of course

micha14:08:48

this gives the task the ability to strictly control how the output of the java compiler is incorporated into the pipeline

micha14:08:08

and the java compiler doesn't have access to anything that could be broken by it

micha14:08:20

it's safely isolated from the rest of the build environment

micha14:08:24

does that make sense?

vikeri15:08:23

Totally! So the files generated are available ephemerally and passed on as long as the boot process runs? But how do I concretely launch a node process pointing to the generated files?

micha15:08:44

i'm not a nodejs expert unfortunately

micha15:08:11

but there must be a way to configure it with input directories, which you can create yourself in temp dirs in your task

micha15:08:25

and you can pass it the path of a temp dr your task creates for its output

micha15:08:47

or if it insists on writing to the input directories (ouch!) you can even accomodate that

vikeri15:08:21

Basically it is as simple running a terminal command with the output directory/file as one of the arguments

micha15:08:54

clojure has functions for shelling out to other processes

micha15:08:34

yes, and boot has boot.util/dosh for when you want the output of the process streamed to stdout in real time, rather than after the process terminates

micha15:08:54

most of the time in build tasks you don't want to wait to see what it's doing

vikeri15:08:02

Yes, preferably

micha15:08:17

so the skeleton would look something like this:

micha15:08:53

(require '[boot.core :as b]
         '[my.compiler :as c])

(b/deftask foop
  [] ;; options here, it's a whole thing
  (let [outd (b/tmp-dir!)]
    (b/with-pre-wrap [fileset]
      (let [inf (->> fileset
                     (b/input-files)
                     (map b/tmp-file))]
        (c/doit :output outd :input inf)
        (-> fileset
            (b/add-resource outd)
            (b/commit!))))))

micha15:08:15

where doit is a function you have that does the nodejs stuff

micha15:08:03

if you need to reorganize the files from the fileset into a different tree in the input directories for the node thing, you can do that too

micha15:08:18

just make another temp dir and copy files to it, changing the paths etc

micha15:08:29

then pass that to the node runner fn

micha15:08:57

boot also has a bunch of efficient patching, diffing, and syncing functions you can use later to speed things up

micha15:08:09

i mean to speed up filesystem operations

micha15:08:35

does that make sense, the example above?

micha15:08:22

if you're not familiar with the functions i used you can see them here https://github.com/boot-clj/boot/tree/master/doc

micha15:08:39

or (doc with-pre-wrap) etc in boot repl

vikeri15:08:50

That makes a great starting point! Not understanding everything off the bat, but I’ll dig into it. Thanks a bunch! Very warm welcome to boot land, just migrated my React Native project today from leiningen.

micha15:08:17

welcome! i hope you enjoy 😉

micha15:08:37

it would be super interesting to see if it's possible to run node in nashorn or something

micha15:08:51

you could then do incremental compilation with caching and so on

vikeri15:08:35

Yeah I’m dong this for testing, so that would be very nice.

micha15:08:25

yeah in any case if you get something going that works we can help you optimize it later, there are a bunch of things boot provides to help with that

dave15:08:42

@vikeri: someone also just posted this brand new boot-npm task the other day, could be helpful? https://github.com/degree9/boot-npm

konukhov15:08:32

Hi! I'm having a weird issue with using a package from Clojars and wondering if it has something to do with Boot. I made a library that have a dependency from external Maven repo. I added this repo to env (via (set-env! :repositories #(conj % '[...]))) and everything works fine locally. When I pushed this lib to Clojars and added it to another project, I got a org.sonatype.aether.resolution.DependencyResolutionException. I guess that Boot should've added this repository to .pom-file, but I couldn't find any mentions of repositories in pom.

konukhov15:08:30

Any ideas? I feel that maybe I’m missing something.

micha15:08:12

@konukhov: are repositories in pom.xml supposed to be added transitively?

micha15:08:23

i didn't think so, but it's confusing so maybe?

micha15:08:44

i thought you needed to explicitly add your own set of repositories

micha15:08:49

in your build

micha15:08:55

to prevent chaos ensuing

micha15:08:10

the same coordinates can exist in different repos with different artifacts

konukhov15:08:18

yeah, I thought that it should be a transitive dependency (never heard of this term before :)).

konukhov15:08:23

yeah, I got it.

micha15:08:20

sure, if you find out that it's not correct please open an issue and we can fix it

micha15:08:49

it's hard to understand where maven the tool stops and general purpose pom.xml starts

micha15:08:08

since maven uses the pom for the build spec too

micha15:08:35

my thinking is that the <repositories> element in the pom is like :repositories in the build.boot

micha15:08:56

and not used in transitive dependency resolution

konukhov15:08:12

yeah, but when you’re using this library from clojars, you have to add those repos manually in each project. anyway, I think that’s okay since I can just specify this in a library documentation.

micha15:08:30

that being said, it might be a good idea to add the <repositories> to the pom, if only to ease debugging

micha15:08:50

someone could look in the pom to see what might be wrong

micha15:08:09

seems like good practice from a security perspective to explicitly choose your own repos and not have dependencies bringing in artifacts from other ones

micha15:08:30

because those artifacts must be unique by id

micha15:08:58

so i could see a malicious dependency bringing in artifacts that will push out other ones

micha15:08:02

from a different repo

konukhov15:08:54

good point

konukhov15:08:20

it might be like npm dependencies hell

micha15:08:26

ugh the worst

flyboarder16:08:00

@vikeri: I still have to extend the npm task to support more options, let me know what you run into and I can see what I can do

vikeri16:08:52

@flyboarder: Well now after some tinkering I have a pretty clear picture of what I need: To include my node_modules folder and my test-runner.js in the original fileset, then to compile cljs and add the resulting js-files to that fileset and ultimately run my testrunner with node (having access to all the files in the fileset). Not sure if that connects to your project but that is what I think I need at least.

flyboarder16:08:09

Ok so my npm task can manage your node packages and put them into node_modules then it includes that folder in your output @vikeri

vikeri16:08:04

@flyboarder: Interesting, what advantage does that give compared to just managing it manually with npm?

flyboarder16:08:36

It shells out to npm, so you get a few benefits, firstly you don't need any npm files in your source, everything is contained in boot file (as task options), modules are cached and moved to project folder so you don't need to redo load them, you also get the option of having multiple npm module lists, for different builds if needed, also since npm is underneath you get all the usual npm stuff @vikeri

vikeri16:08:33

Ok cool! So no node_modules folder?

flyboarder16:08:14

@vikeri: right it's managed underneath for you

flyboarder16:08:04

I added a new option so if your project uses bower, you can call the bower task and it will use the npm task to install itself then run

vikeri16:08:14

This will either be very helpful or adding unnecessary abstraction for the #C0E1SN0NM community. I think I have to have the node_modules folder in sight for the RN packager but @pesterhazy is more suitable to see how this could be useful.

flyboarder16:08:06

@vikeri: the folder should be available on the fileset after its run

flyboarder16:08:24

So tasks which follow it don't know the difference

kenzaburo19:08:48

Hello! I'm using boot-cljs and just upgraded to the lastest version of clojurescript (need :preloads) and now I get the following error in advanced compilation only: > clojure.lang.ExceptionInfo: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher; > data: {:file "/tmp/boot.user787106068256971973.clj", :line 19} > java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher; > com.google.javascript.jscomp.parsing.JsDocInfoParser.validTemplateTypeName JsDocInfoParser.java: 1216 Here are my boot.build versions [org.clojure/clojure "1.9.0-alpha10"] [org.clojure/clojurescript "1.9.89"] [adzerk/boot-cljs "1.7.228-1"] My boot version is 2.6.0

kenzaburo19:08:36

has anyone encountered this before?

micha19:08:12

looks like a dependency issue

micha19:08:18

of google closure

micha19:08:28

boot show -p might tell you

kenzaburo19:08:49

oh cool i didn't know about this command

kenzaburo19:08:03

given that the other search hits on google point to a guava version mismatch, this is probably the culprit in my case: > [!] com.google.guava/guava > ✘ 19.0 > reagent > org.clojure/clojurescript > ✔️ 18.0 > com.cemerick/piggieback > org.seleniumhq.selenium/selenium-java > org.seleniumhq.selenium/selenium-remote-driver > org.seleniumhq.selenium/selenium-server

micha19:08:59

looks incriminating

kenzaburo19:08:19

commenting out selenium, solved it! thanks,

lambder20:08:34

@danielsz: when I add system task I get:

lambder20:08:35

clojure.lang.ExceptionInfo: No such var: dir/scan-dirs data: {:file "system/boot.clj", :line 54} java.lang.RuntimeException: No such var: dir/scan-dirs

lambder20:08:46

what do I miss here?