This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-05
Channels
- # bangalore-clj (4)
- # boot (196)
- # chestnut (1)
- # cider (4)
- # clara (3)
- # cljs-dev (23)
- # cljsjs (28)
- # cljsrn (1)
- # clojure (79)
- # clojure-art (1)
- # clojure-berlin (1)
- # clojure-hk (17)
- # clojure-italy (5)
- # clojure-korea (1)
- # clojure-russia (21)
- # clojure-spec (5)
- # clojure-uk (26)
- # clojurescript (125)
- # core-async (1)
- # cursive (23)
- # datomic (7)
- # emacs (17)
- # hoplon (51)
- # jobs (2)
- # leiningen (2)
- # om (11)
- # om-next (26)
- # onyx (39)
- # pedestal (9)
- # proton (4)
- # re-frame (43)
- # reagent (1)
- # ring (2)
- # slack-help (12)
- # sydney (4)
- # test-check (9)
- # yada (40)
Is there any reason to use (get-env :directories)
instead of (get-env :source-paths)
when setting the refresh dirs?
@dominicm directories is also tmp dirs and not what you provide in source/resource etc
source-paths
is mirrored in a dir in (get-env :directories)
hypothetically you could generate clojure files as part of your build — they would not show up in source-paths
@martinklepsch Hmm, that does pose some potential problem.
Although, other than cljx (which is deprecated), I doubt that's a more common practice than using cljc
files, which is the bug I'm trying to fix.
Although, I've just seen https://github.com/Deraen/boot-ctn/blob/master/src/deraen/boot_ctn.clj has a remove-fn
, which could be used to remove problematic paths.
I've been thinking about this for some days
And there doesn't seem to be easy solution
Boot-cljs will write all input files to fileset and they will be part of classpath, tools.namespace will reload those
This will sometimes cause problems if those cljc namespaces define protocols
@juhoteperi Out of interest, did you run into something similar to https://github.com/stuartsierra/component/issues/45
Yeah, looks like it. It's highlighted itself very brightly when you use bidi with cljs and clj.
Using source-paths (the dirs in working dir) is (or at least was) very problematic because then tools.namespace file tracker would be looking at different files than those that are available in classpath (temp dirs managed by boot)
That is how Boot works with c.t.n 0.2 and without boot-ctn (or manual set-refresh-dirs)
At list that's why I think boot-ctn exists... 😄
c.t.n 0.3 uses clojure.java.classpath and automatically uses the temp dirs
And re: why it is very problematic, if file watcher is looking and working dir it might decide to reload some namespace but the changes might not be yet reflected on the temp dirs
c.t.n reloads ns -> old ns is reloaded -> when new file is in temp dir, it is not reloaded again
No, just the opposite! 😄
If you use non-temp dirs (working directory) that is going to happen
But when c.t.n looks at the temp dirs, it will try to reload namespaces only when the files are really available in classpath
How do you remove the cljs/cljc files from the classpath then, by blacklisting the folder?
Won't be very easy to blacklist the folder as it is created by Boot-cljs
Nope, I'm not currently using problematic libraries with Boot projects
I fixed one Lein project where it was easy to just blacklist the cljs output dir
You could "catch" the files that were added by the cljs task (by comparing the fileset?) and remove those I guess. The temp dirs only is a problem if you're using 0.3 of c.t.n (which is alpha)
I'm wondering, is it important that the output directory is on the classpath?
@juhoteperi If you use (set-refresh-dirs "src" "dev" "test")
on 0.3 of c.t.n, then it would only read the input files in the first place? It doesn't matter if it's copied or not?
@martinklepsch Yeah, to serve the assets
@dominicm C.t.n doesn't reload files from refresh-dirs, those dirs are only to check which namespaces are reloaded using (require ... :reload)
which will check the classpath
@dominicm ah right
@juhoteperi Oh! I understand now. That's a pain.
Also the temp dir watched by c.t.n is not the same temp dir as is created by Boot-cljs
Boot manages a few directories with different roles, one for resource files in fileset IIRC, and files from Boot-cljs temp dir are synced into that dir
It also contains files from other tasks in pipeline, like CSS from Less
@juhoteperi So if c.t.n watched the temp dir that boot created for source files (not resource files), that might work?
https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/core.clj#L123 is private, but accesible
It needs to watch both as some clj code might (and probably will) be on resource paths
But! Watching user source + resource dirs could work!
Looks like user dirs are those from the project dir, i.e. not created by tasks
like boot-cljs
boot.user=> (apply clojure.tools.namespace.repl/set-refresh-dirs (map (memfn getPath) (concat (#'boot.core/user-source-dirs) (#'boot.core/user-asset-dirs)))) ("/home/juho/.boot/cache/tmp/home/juho/Source/saapas/lxf/aixfad" "/home/juho/.boot/cache/tmp/home/juho/Source/saapas/lxf/coz8kz")
this could work as a workaround
It should
Hmm, what temp paths did you try? These from user-* functions?
(apply clojure.tools.namespace.repl/set-refresh-dirs (#'boot.core/user-source-dirs))
worked for me, obviously needs asset dirs attaching
(System/getProperty "fake.class.path")
should show the files in classpath
So maybe the copying isn't a problem? If that's consistent & searches are sequential.
@juhoteperi Not entirely sure how I'd test whether or not we need to do this. Do you know?
Nope. Maybe it works nowadays.
if I want to use parallel builds in clojurescript, do I write (cljs :compiler-options {:parallel-build true})
?
@juhoteperi I've never seen code in the asset-path, when does that happen?
Why is :optimizations
not under :compiler-options
is what made my ask that question. Convenience?
@borkdude Yes, top-level optimizations is for convenience
top-level :source-map
option has also some additional logic to properly set source-map filepath when using other optimizations settings than :none
Ah nvm, that's not right, the logic is used even if :source-map
is only set under :compiler-options
hi @dominicm @juhoteperi , catching up on the ctn conversation
@micha You might have an interesting input, I'll try give you a summary:
Building cljs, copies .cljc
files onto the classpath as part of the build process. These cljc
files then get picked up by c.t.n, and refreshed. So you end up refreshing things like bidi. This causes protocols to get wiped, which causes errors.
My solution was to specify only to refresh src
, dev
and test
(traditional source-paths, excluding resource-paths), but @juhoteperi mentioned it might conflict with temp paths a little.
Yes, c.t.n doesn't look at cljs files
right but i mean the problem is not the cljc files themselves, but the copies that are in the output dir for source maps, right?
I'm not sure what the clojurescript compiler does with them (they might need to be on the filesystem for google closure for example -- probably not)
if you have a cljc file that is compiled by cljs compiler, you will have a copy of that cljc file that is present in the "output dir" that will be in your web root
Hmm, interesting, I wonder why c.t.n doesn't ignore files in "wrong" paths
I guess it will just take any changed files and read ns
from those
there isn't really a good use case for subsequent tasks to have any of that on the classpath i guess
Hmmm. Asset files are not available on classpath and thus it won't work with ring resource handlers?
Would that break the ability to serve the cljs files from the resource path (e.g. an uberjar)
Asset files are added to uberjar
One problem is that Ring resources handler doesn't know about our file roles
yeah and those files aren't used for computing, they're just assets used to link to in the browser
@juhoteperi yes this is why i like to use boot-jetty, because it does what the uberjar would do
it makes a pod with the stuff that will be on the uberjar classpath for its classpath, i should say
so the resource middleware works the same in dev with boot-jetty as it works in the production uberjar
Boot-jetty runs the app web handler logic inside a pod? So REPL won't work?
Sounds very slow
If the require will always run from the local directories first, I see no problem with a whitelist still.
Does boot have a way to suppress output?
hmm can I use that within a task to suppress the tasks im using?
like a global var?
id like to do something like that
so if im just calling tasks that use util/info could I not swap the verbosity level between tasks?
cool i will try
print*
seems to check verbosity each time
does each task get it’s own pod?
so how do I go setting things in a pod?
right now im just comp
ing tasks
basically my snippet above
one sec ill post
So i’d like to provide my own output
it works really well just ugly as heck in console, really underlying task errors dont help much i’d like to provide it in my wrapper task
https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj#L416-L420
your case is a little more complicated because you want to re-enable printing after your task runs
interesting ill give that a go
(let [*out*' *out* *err*' *err*]
(comp
(eat-output)
(semgit/...)
...
(restore-output *out*' *err*')))
if restore-output needs to have access to the output that was eaten you could have the StringWriters in lexical scope too and pass them in to both
awesome thanks!
yeah i can make a task that has a pre post tho right
(let [out1 *out*
err1 *err*
out2 (new StringWriter)
err2 (new StringWriter)]
(comp
(redirect-output out2 err2)
(semgit/...)
(semgit/...)
(redirect-output out1 err1)))
@micha like this? not sure if this would work with the macro you were thinking
^note above does not work… yet
I updated the snippet with a working silencer task.
I dont yet know how to re-enable output other than a task which does the opposite.