Fork me on GitHub
#boot
<
2016-03-09
>
danielsz00:03:29

@alandipert: I don't think any tooling relies on it. The user namespace is there because Rich had to devise a default ns when you do java -cp clojure.jar clojure.main

danielsz00:03:26

@alandipert: Not a fact, an interpretation.

danielsz01:03:36

@alandipert: Pretty sure tools.namespace doesn't rely on it.

danielsz01:03:35

@alandipert: Stuart Sierra did leverage user.clj in his reloaded workflow post, but that part was never formalized in a library.

danielsz01:03:30

@alandipert: As a matter of fact, that is the part that James Reeves formalized in his reloaded.repl library, but it doesn't use user.clj

danielsz01:03:58

@dm3 I think the losing of var definitions you describe is the classical gotcha of tools-namespace, described here https://github.com/clojure/tools.namespace#warnings-and-potential-problems.

danielsz01:03:19

@dm3 "Be careful when reloading the namespace in which you run your REPL."

danielsz01:03:42

@dm3 Boot doesn't interfere here at all.

dm305:03:21

@danielsz: that's probably it. However, all of the stateful vars were in other nses which should have been cleaned up properly by mount. Maybe in my case mount.core got refreshed by tools.namespace which made it lose its state... Quite possible as I set the refresh-dirs to the full classpath

kenbier06:03:55

im seeing this warning when running boot-cljs-test

kenbier06:03:57

" WARNING: Replacing ClojureScript compiler option :main with automatically set value."

kenbier06:03:08

has anyone seen this before, and know why this is happening?

kenbier06:03:53

im wondering if the library is defining its own entry point, or if there is a problem with my code. the tests are running, but im not sure why im seeing that warning

kenbier07:03:20

looks like it boot-cljs introduced a new warning message in the latest version.

dm310:03:30

So I was thinking a bit about the user ns, or the 'user' code that is supposed to be injected into the NS that the REPL uses. Coming from lein people will usually have something like a dev/user.clj file and expect that it will get loaded in the dev task (having appropriate source-paths, obviously). To replicate that in Boot we can just put the user.clj code into the build.boot itself or refer the user ns from the dev task. I think this is preferable as the 'blessed' way, the other option being the init-ns in the repl task, as you still have access to all of the boot functions in the boot.user ns. Also, I'd guess people will usually stumble to get tools.namespace working. There's a Wiki entry https://github.com/boot-clj/boot/wiki/Repl-reloading which recommends doing (apply tn/set-refresh-dirs (get-env :directories)). This has an interesting side effect of refreshing the namespaces that are compiled for both Clojure and Clojurescript (e.g. cljc files) even if you're only using them through Clojurescript. So if you are using something like mount on the client side, the mount.core namespace will get reloaded on the JVM - the code is in the same file! This is bad, as the namespace has state that you don't want to touch. Not sure what the proper solution is here, seems like we'd want to exclude clojurescript resources from tools.namespace refresh dirs. Please discuss and I'd like to add something to this effect to the "Coming from Leiningen" Wiki page.

micha13:03:54

@kenbier: the cljs task sets the :main compiler option, so it's overwriting your setting, that's why you see the warning

dm313:03:44

@micha - does anything I wrote make sense? simple_smile

micha13:03:37

one additional option is to have a directory with user.clj in it, and add that to the classpath via BOOT_JVM_OPTIONS

micha13:03:33

not sure if that gives you anything that the method you describe doesn't

dm313:03:41

that will end up in the user ns, then to replicate lein "experience" you can set :init-ns to user

dm313:03:06

I'm more interested in a solution to the second issue, although there doesn't seem to be a simple one

micha13:03:16

tools.namespace?

micha13:03:20

that issue?

dm313:03:33

yes, reloading of cljc files from libraries

micha13:03:34

i don't really use the cljc stuff

micha13:03:38

so i have no idea

dm313:03:36

lucky you simple_smile most of those don't have any state

dm313:03:17

and it only surfaces on the first refresh or if you do refresh-all

dm313:03:28

but still, not pleasant

micha13:03:40

i basically use a minimum amount of repl infrastructure

dm314:03:18

how do you make sure the repl has up to date code?

micha14:03:45

i to (require ... :reload)

dm314:03:29

ok, down to the basics simple_smile I mostly rely on recompiling nses from VIM, but sometimes it gets into a state where the app should be restarted

micha14:03:42

it's probably not the most productive setup, but i just don't have time to tinker with it

dm314:03:44

so I use refresh + stop + start

micha14:03:57

yeah i restart my repl pretty often

micha14:03:08

i use a separate repl in tmux

micha14:03:14

which vim can connect to pretty reliably

dm314:03:55

the problem is - most people now work with tools.namespace, so we need some sort of a solution or at least a description of the problem in Boot

dm314:03:11

I'll add that to Lein wiki page

tolitius14:03:04

@dm3 interesting, I thought: https://github.com/tolitius/mount/blob/master/src/mount/core.cljc#L18-L20 would shield it from tools.namespace. I also don't really use tools.namespace [use it on one older project], so maybe I am missing something behind its refresh-all concept.

dm314:03:17

@tolitius: that should add a metadata value under :clojure.tools.namespace.repl/load

dm314:03:01

otherwise that should work

dm314:03:51

how do you reload your code? just curious

tolitius14:03:03

@dm3: usually recompiling a namespace in the editor (I use vim) that is connected to the repl reloads that namespace. if there are problems, I do :reload / :reload-all, but not that often. the reason I used tools.namespace before was to trigger restart of resources (i.e. db/queue/socket connections, event loops, schedulers, etc..), but now I just do (mount/stop) / (mount/start) to do that

dm314:03:26

so far 66% of respondents of my survey don't use tools.namespace

dm314:03:56

let's see if I find person #4 to ask

dm314:03:14

also 100% of respondents use vim, which is awesome! simple_smile

mobileink15:03:43

@alandipert, @flyboarder : FYI, in case you haven't come across this, polymer webjars may not be so reliable. a specific case: github-com-PolymerElements-iron-icon seems to use the wrong jar: github-com-polymerelements-iron-icon-1.0.7.jar (note the case, PolymerElements is 1.x, polymerelements is some other version, apparently)

alandipert15:03:54

@mobileink: thanks. yeah i think i might be over polymer/webjars already

mobileink16:03:05

me too. i've implemented support for webjars but you can't do much if the jars are broken. at least with bower you know its officially maintained by the Polymer folks.

kenbier17:03:03

@micha right i saw that, i shouldve been more clear. i was wondering if that behavior was opt out or not. i saw then docs mentioned setting up a test edn file though it made no difference, perhaps they needed to set their own entry point to build the test suite?

micha17:03:33

@kenbier: how is :main being set?

kenbier18:03:19

ah it looks like i can supply i suite-ns

kenbier19:03:54

@micha do you have any examples on how to filter namespaces to test using boot-test?

kenbier19:03:35

something simple like filtering any ns that dont include “-test” ?

alandipert20:03:27

@kenbier: you could do like... boot test -f '(>= (.indexOf (str (.-ns %)) "test") 0)'

alandipert20:03:16

make that (.contains (str (.-ns %)) "-test")

kenbier20:03:31

thanks! if i want to include that in the task-options, can i just set :filters of the test map to a set containing the expr, and qoute that expr? i cant get that part working

kenbier20:03:58

(task-options!
 test {:filters '#{
                   '(.contains (str (.-ns %)) "-test")
                   }})

micha20:03:41

@kenbier: if you do (doc test) in the repl you can see the types of the option arguments

micha20:03:10

you can see the docstring tells you about what type of argument :filters expects

micha20:03:19

:filters          #{edn}  The set of expressions to use to filter namespaces.

micha20:03:32

that means it expects a set of EDN forms

alandipert20:03:52

@kenbier: i think that will work

micha20:03:01

the double quoting though

micha20:03:07

will be a problem, no?

alandipert21:03:36

(task-options!
 test {:filters '#{
                   (.contains (str (.-ns %)) "-test")
                   }})

taylor.sando22:03:29

Is there a way of excluding subdirectories when setting the source-paths with set-env! ?

micha22:03:55

you can create a file named .bootignore in your project dir

micha22:03:08

it should have one java-style regex pattern per line

micha22:03:05

if that file exists then the paths of each file in the :source-paths etc will be matched against the regexes in that file

micha22:03:14

and if any match the file will be excluded

micha22:03:27

so for example if you have a directory src in your project

micha22:03:38

and you have :source-paths #{"src"}

micha22:03:08

and you want to exclude the subdirectory src/foo, you can make a .bootignore file with the following contents:

taylor.sando22:03:54

I reason I am thinking about this that I want to have two servers, an API server and a webpage server. The webpage server serves the clojurescript app. The clojurescript app and API server share some cljc files (mostly datomic/datascript stuff). I'm just wondering the best way to split these up, or have them in the same repository.

micha22:03:24

you can also do something like this in your build.boot if you don't want to make the .bootignore file:

micha22:03:43

(swap! boot.core/bootignore conj #"^foo/")

taylor.sando22:03:57

I'll look into using

boot.core/bootignore
and keep everything in the same repo.

micha22:03:44

yeah it's flexible enough i think you'll find one of the permutations works for your setup

seancorfield23:03:12

@micha: With the push to get 2.6.0 out, do you want to roll boot-new in at this point? I was planning to keep it separate for a while for the community to shake glitches out of it but I was also thinking 2.6.0 would be further away at this point…