This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-15
Channels
- # aws-lambda (3)
- # beginners (17)
- # boot (65)
- # cider (3)
- # cljs-dev (7)
- # cljsrn (82)
- # clojure (82)
- # clojure-italy (1)
- # clojure-russia (25)
- # clojure-spec (56)
- # clojure-uk (5)
- # clojurescript (52)
- # css (2)
- # datomic (6)
- # emacs (1)
- # hoplon (9)
- # jobs-discuss (5)
- # leiningen (8)
- # mount (2)
- # nginx (1)
- # off-topic (2)
- # om (1)
- # om-next (9)
- # perun (13)
- # portland-or (1)
- # re-frame (13)
- # reagent (20)
- # remote-jobs (2)
- # ring (5)
- # spacemacs (1)
- # specter (10)
- # untangled (5)
- # yada (6)
What is the best practice for appending a string to a file in boot. (spit file string :append true)
throws errors at me.
It's inside a task and fileset operations and all that jazz.
I've just resorted to (spit (str (slurp file) string))
but was thinking there might be a better way.
@grounded_sage I think you're supposed to use a tmp directory for this - make all your file modifications there, and then boot.core/commit!
here's a code example: https://github.com/hashobject/perun/blob/master/test/io/perun_test.clj#L84
there, tmp
is a directory returned from boot.core/tmp-dir!
, and new/changed files are written to it
So, in preparation for a release next week, I’m getting aggressive about having a clean dependency tree and adding exclusions to remove all conflicts. I’m using this snippet, which is working really well: https://github.com/boot-clj/boot/wiki/Snippets#check-dependency-conflicts. So thanks @seancorfield!
One follow-up question… one class of error I’ve hit a couple times, that’s really annoying, is when I overzealously add too many exclusions and remove all instances of a dep from a project. The problem with this is that it doesn’t show up except as some arcane JVM exception at runtime, when a particular code path is excercised.
Is there any easy way of enhancing the check-dependency-conflicts snippet so it will also warn if you’ve excluded all versions of a dependency?
@luke how about resolving dependencies without any user-added :exclusions
, then diff the resulting list of deps by group/artifact-id?
like remove all :exclusions
from the user's :dependencies
, then resolve and test against the current env resolved deps
i guess that would fall down when the user wants to exclude all versions of a dependency
like when it's just cruft that you don't need in production but wasn't specified as :scope "test"
in a dependency
though that can be a bit dangerous, since sometimes it will seem like it works until it doesn't
you could use metadata on the group/artifact-id symbol to suppress the check in that case
@luke you know what, i think this would be a good thing to add to boot show -p
output too
it would be nice to see if you've been overzealous with the exclusions when you do show -p
Not going to do it myself this week since I’m gearing up for an Arachne release, but I’ll keep that in mind next time I’m hacking on boot.
one request if you do mess around with it: in addition to adding it to boot show
, it’d be nice if it were easy to invoke programmatically, so I can add it as a guard in my test
and deploy
tasks.
@micha so for showing an alternative approach/improvement for task options, I was thinking of patching bootlaces...It is a project with common stuff and it can be a good point for this kind of thing. What I have in mind is a modified deftask, and I feel another custom lib is a bit overkill. What do you think?
It would basically do two things, intern for you the symbol associated with the task in boot.user
and pass params to the task itself, where the parameters this time are in a map
it should be possible to support one map argument for tasks in boot, without breaking changes i think, too?
I think so, so basically this macro will be easy to port upstream
Just want to see if the approach is sound
@luke such as globally excluding ClojureScript from a purely server side project. There you definitely want all versions excluded to keep your uberjar smaller.
@seancorfield agreed… usually its best to keep a totally separate “build time” and “runtime” class path, but there are libraries that declare dependencies in such a way that that’s difficult.
RE this classpath & uberjar stuff, it's perhaps worth noting that Clojure's AOT routine can't consider the scope of dependencies. And it's therefore possible to end up with dev dependencies in your uberjar.
@bhagany: yea I've done the tmp dir and commit ect. It's just the :append true seems to throw an error when I try and append a string to a file.
@grounded_sage and the file is in a tmp dir?
@bhagany: only just woken up. If I remember correctly it was saying that I needed to pass a value to true or something like that.
(defn make-atomic-styles [in-file out-file]
(doto out-file
io/make-parents
(spit (str (slurp in-file) " " (styler/get-css-str false)))))
(deftask add-atomic-styles
"Adds atomic styles to final css"
[]
(let [tmp (tmp-dir!)]
(with-pre-wrap [fileset]
(empty-dir! tmp)
(let [in-files (input-files fileset)
css-file (by-name ["garden.css"] in-files)]
(doseq [in css-file]
(let [in-file (tmp-file in)
in-path (tmp-path in)
out-path in-path
out-file (io/file tmp out-path)]
(make-atomic-styles in-file out-file)))
(-> fileset
(add-resource tmp)
commit!)))))
I was trying to do (spit in-file (styler/get-css-str false) :append true)
. What I have works. Just thought there might be a better way
That structure is basically the same as the example given for filesets in boot docs
It writes to here doesn't it (io/file tmp out-path)
?
Ah I see
Trying to do a mutation outside of a tmp-dir
str
is probs the simplest solution then
@juhoteperi I was thinking, why don't I merge the PR in boot-figreload (which works fine, I have been using it for two weeks, standard setup) and we publish the first snapshot? It can be better for faster feedback I guess. I can push it to powerlaces
group if you agree