This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (3)
- # beginners (60)
- # boot (95)
- # braid-chat (2)
- # cider (12)
- # clara (1)
- # cljsrn (30)
- # clojars (2)
- # clojure (58)
- # clojure-art (1)
- # clojure-austin (3)
- # clojure-madison (11)
- # clojure-miami (6)
- # clojure-norway (3)
- # clojure-poland (13)
- # clojure-russia (67)
- # clojurescript (108)
- # core-matrix (39)
- # cursive (15)
- # data-science (6)
- # datomic (3)
- # hoplon (7)
- # jobs (9)
- # jobs-discuss (40)
- # ldnclj (5)
- # off-topic (6)
- # om (91)
- # proton (9)
- # re-frame (29)
- # reagent (7)
- # spacemacs (3)
- # testing (9)
- # yada (1)
@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
@alandipert: Stuart Sierra did leverage user.clj in his reloaded workflow post, but that part was never formalized in a library.
@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
@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.
@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
" WARNING: Replacing ClojureScript compiler option :main with automatically set value."
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
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
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.
cljs task sets the
:main compiler option, so it's overwriting your setting, that's why you see the warning
one additional option is to have a directory with user.clj in it, and add that to the classpath via BOOT_JVM_OPTIONS
that will end up in the
user ns, then to replicate lein "experience" you can set
I'm more interested in a solution to the second issue, although there doesn't seem to be a simple one
ok, down to the basics I mostly rely on recompiling nses from VIM, but sometimes it gets into a state where the app should be restarted
it's probably not the most productive setup, but i just don't have time to tinker with it
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
@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
@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-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/start) to do that
@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)
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.
@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?
@kenbier: you could do like...
boot test -f '(>= (.indexOf (str (.-ns %)) "test") 0)'
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
@kenbier: if you do
(doc test) in the repl you can see the types of the option arguments
Is there a way of excluding subdirectories when setting the source-paths with set-env! ?
if that file exists then the paths of each file in the :source-paths etc will be matched against the regexes in that file
and you want to exclude the subdirectory
src/foo, you can make a .bootignore file with the following contents:
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.
you can also do something like this in your build.boot if you don't want to make the .bootignore file:
yeah it's flexible enough i think you'll find one of the permutations works for your setup