This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-27
Channels
- # aleph (3)
- # beginners (89)
- # boot (198)
- # cbus (4)
- # cider (11)
- # clara (2)
- # cljs-dev (27)
- # cljsrn (4)
- # clojure (141)
- # clojure-austin (4)
- # clojure-italy (11)
- # clojure-nl (1)
- # clojure-poland (2)
- # clojure-russia (35)
- # clojure-spec (33)
- # clojure-uk (55)
- # clojurescript (111)
- # core-logic (15)
- # cursive (2)
- # datascript (47)
- # datomic (132)
- # emacs (4)
- # jobs (1)
- # lein-figwheel (13)
- # leiningen (15)
- # lumo (20)
- # off-topic (110)
- # om (8)
- # onyx (20)
- # parinfer (2)
- # protorepl (1)
- # re-frame (36)
- # reagent (5)
- # remote-jobs (1)
- # ring (2)
- # ring-swagger (5)
- # specter (6)
- # uncomplicate (3)
- # unrepl (77)
@lwhorton this gives the basic ideas
@micha @alandipert and all, I am planning on moving https://github.com/Lambda-X/boot-pack-source to boot-clj
. It will be renamed as well to boot-sources
. Any objection?
none from me
Moved! https://github.com/boot-clj/boot-sources There will be a nice task for source file concatenation (needed by unrepl
)
this is just a general conceptual question: I seemed to have misunderstood the purpose of (commit! fileset)
. I had a task that was caching the previous fileset so it could do a (fileset-diff @old new)
. I would only commit to the fileset if 1) there was a diff between the prev fs and the current fs 2) there were files relating to my task (filtered using the fileset query api) that changed. If both 1 and 2 were not satisfied, I would only return the fileset exactly as provided, and would not invoke commit!
. However on multiple reruns I kept getting invalid nameToPath
(goog.closure + clojurescript’s file loader) errors. Looking further it seemed that boot’s .boot/cache/.../hash/hash
caching mechanism caused the “problem”.
So it seems that even if a task does not want to “do” anything for the given fileset diff, it still needs to commit it’s closed-over tmp-dir!
to the fileset, otherwise boot will not spit out the proper files into the new cache directory?
Hello people, I have troubles merging the file BOOT_HOME/profile.boot
and MY/PROJECT/buid.boot
. I followed the instructions from https://github.com/jsofra/data-scope to have it always available, instructions are :
(set-env! :dependencies #(conj % '[jsofra/data-scope "0.1.2"]))
(boot.core/load-data-readers!)
(require 'data-scope.inspect)
Then my build.boot
file does (set-env! :dependencies '[[w/x "x.x.x"] [y/z "x.x.x"] ...])
normally. But my profile deps aren't included when I launch a boot repl
in my project. Then I thought, set-env!
of my project erase the dependencies, so I tried updating them instead by following the official docs (https://github.com/boot-clj/boot/wiki/Boot-Environment#update-env-value). I tried various syntaxes with no success :
;; in project's build.boot
;; #1
(set-env! :dependencies #(conj % '[[...]])) ;; throws java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to clojure.lang.Named
#2 and #3
(set-env! :dependencies #(conj % [[...]]) ;; dependencies vector not quoted, throws java.lang.ClassNotFoundException: org.clojure
(set-env! :dependencies #(concat % [[...]]) ;; concat + dependencies vector not quoted, throws java.lang.ClassNotFoundException: org.clojure
#4
(set-env! :dependencies #(concat % '[[...]]) ;; no error, not working
i think in your pasted build.boot you could try (set-env! :dependencies #(into % '[[...]]))
?
conj
would do like (conj [['foo/bar "1.0"] ['baz/baf "2.0"]] [['quux "3.0"]]) => [['foo/bar "1.0"] ['baz/baf "2.0"] [['quux "3.0"]]]
not working : (pprint (get-env :dependencies))
after running boot repl
does not include the jsofra/data-scope
stuff
$ cat $BOOT_HOME/profile.boot
(set-env! :dependencies #(conj % '[jsofra/data-scope "0.1.2"]))
(boot.core/load-data-readers!)
(require 'data-scope.inspect)
Well, (merge-env! :dependencies #(into % '[[]]))
throws java.lang.IllegalArgumentException: Don't know how to create ISeq from: boot.user$eval47$fn__48
@micha is it worth having docs & guides default to suggesting merge-env!
all the time? Seems sensible, especially if you stick it in a task.
@djebbz sorry, I meant your original use of set-env!
, (merge-env! :dependencies '[[yada "1.2.1"]])
I even added (println "***********\n PROFILE.BOOT \n***********")
in profile.boot
, not printed when I start a REPL
My complete profile.boot (very small) :
(set-env! :dependencies '[[jsofra/data-scope "0.1.2"]])
(boot.core/load-data-readers!)
(require 'data-scope.inspect)
(println "***********\n PROFILE.BOOT \n***********")
if you don't see that in the boot -b ...
output there must be something going on with BOOT_HOME
boot.properties :
#
#Thu Dec 01 16:19:49 CET 2016
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.9.0-alpha15
BOOT_VERSION=2.7.1
BOOT_EMIT_TARGET=no
boot.user=> (System/getEnv "BOOT_HOME")
java.lang.IllegalArgumentException: No matching method: getEnv
clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: No matching method: getEnv, compiling:(/tmp/boot.user3111401912711538582.clj:1:1)
@micha does boot.properties search upwards ever? '@djebbz do you have the same result when you start from /tmp
?
as a quick check to convince yourself you can make a symlink from /.boot to /.config/boot or something
Downloading ...
Running for the first time, BOOT_VERSION not set: updating to latest.
#
#Thu Jul 27 17:21:24 CEST 2017
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_VERSION=2.7.1
BOOT_CLOJURE_VERSION=1.7.0
now that you fixed your BOOT_HOME setup it sees your boot.properties file in there for the first time
For the notice, I still have to change my original set-env!
to have the deps from my profile.boot working in my project's repl
For the notice, I open an issue in the new tools.deps.alpha
repo from Clojure core for this exact thing, hoping that the new clj
tool will store and search stuff in ~/.config/clojure
But regarding Boot, it's already nice to have BOOT_HOME
, it allows anyone to customize it
Oh, the dependencies in profile.boot
(loaded with (set-env! :dependencies '[[]]
) worked in my project, which loaded them the same way. No merge-env!
, no into
, concat
, whatever. Still worked.
so the :dependencies in boot env are really just informational once the deps have been added to the classpath
that is because there is no way to remove a class from a classloader once it's in there
the only issue with overwriting :dependencies is that subsequent maven operations also won't know about those deps
oh, ok, so chain of (set-env! :dependencies '[[]]) in the various files that boot understands will always work
for dev tooling it's usually ok to load some in the profile, because those generally won't have lots of transitive dependencies
you can always load dev dependencies into a pod, which eliminates transitive deps completely
and they have protocols and stuff that let you do things like evaluate expressions in the pod and obtain the result
and in the pod you have a namespace usually with functions that will form the pod's api
then you can take the code that creates the pod and so on and make that a clojure library and deploy a jar to clojars
now in a project you can add that dependency (it won't have any transitive dependencies because it loads all the things it needs into a pod)
and once that dependency is loaded it will usually have some api namespace with functions you can call in your dev environment
if you look on the classpath in the repl, none of the maven pomegranate things are on the classpath at all
So if understand correctly, if I put my deps in a pod and expose what I like in some namespace in profile.boot
, I could always use this dev namespace for any project without ever having a conflict ?
the one place where pods won't work is when the code needs to run in the same clojure runtime
if the nrepl server was started in its own isolated pod it wouldn't have access to your project vars
but most dev tooling stuff just needs to perform some work like compile, transform, etc
I should give it a try. I discovered at work before the lucidity lib, which has in
/`inject`, which take some deps declaration (with :refer
etc.) and inject them all in a namespace named .
. I was shown its usage in a lein repl, and the guy was able to do ./pprint
for example from any namespace from his repl.
If I manage to combine this stuff and a pod, I would never have to worry about conflict.
The lib https://github.com/zcaudate/lucidity the in
/`inject` functions : http://docs.caudate.me/lucidity/lucid-core.html#core-inject
2. your dev dependency is itself a dependency of your project, possibly via transitive dependency
so as long as the inject dep itself doesn't have transitive dependencies you're probably fine
Sorry, I'm totally new to this class of problems. Say in my dev deps (in profile.boot
) I load deps X which depends on deps Y version 1. My project loads deps Z which depends on deps Y version 2. If I use the pod trick, there's never going to be a conflict ?
Moved! https://github.com/boot-clj/boot-sources There will be a nice task for source file concatenation (needed by unrepl
)