Fork me on GitHub
#boot
<
2017-01-15
>
grounded_sage01:01:27

What is the best practice for appending a string to a file in boot. (spit file string :append true) throws errors at me.

grounded_sage01:01:50

It's inside a task and fileset operations and all that jazz.

grounded_sage01:01:57

I've just resorted to (spit (str (slurp file) string)) but was thinking there might be a better way.

bhagany16:01:14

@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!

bhagany16:01:53

there, tmp is a directory returned from boot.core/tmp-dir!, and new/changed files are written to it

luke16:01:21

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!

luke16:01:19

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.

luke16:01:48

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?

micha17:01:48

@luke how about resolving dependencies without any user-added :exclusions, then diff the resulting list of deps by group/artifact-id?

micha17:01:33

like remove all :exclusions from the user's :dependencies, then resolve and test against the current env resolved deps

luke17:01:40

hm, yeah, that would certainly work

micha17:01:49

it should be mostly in cache

micha17:01:23

i guess that would fall down when the user wants to exclude all versions of a dependency

luke17:01:50

yeah… I can’t think of a situation where I’d want to do that off the top of my head

luke17:01:55

but I’m sure it would happen eventually

micha17:01:58

like when it's just cruft that you don't need in production but wasn't specified as :scope "test" in a dependency

luke17:01:04

oh, true

luke17:01:21

though that can be a bit dangerous, since sometimes it will seem like it works until it doesn't

micha17:01:36

haha right

micha17:01:44

i don't mess around with it

micha17:01:56

you could use metadata on the group/artifact-id symbol to suppress the check in that case

micha17:01:13

if you need to support that kind of thing

micha17:01:04

@luke you know what, i think this would be a good thing to add to boot show -p output too

micha17:01:30

it would be nice to see if you've been overzealous with the exclusions when you do show -p

luke17:01:12

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.

micha17:01:38

awesome, i'll hack a bit myself

micha17:01:48

some mlk day hacking

luke17:01:28

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.

micha17:01:53

trying to get one of our internal tools ready for open source

micha17:01:21

kind of a pain 🙂

luke17:01:02

oh I feel that

richiardiandrea18:01:58

@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?

micha18:01:33

sure, that sounds ok to me

richiardiandrea18:01:25

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

micha18:01:21

interesting

micha18:01:13

it should be possible to support one map argument for tasks in boot, without breaking changes i think, too?

richiardiandrea18:01:47

I think so, so basically this macro will be easy to port upstream

richiardiandrea18:01:07

Just want to see if the approach is sound

seancorfield19:01:39

@luke such as globally excluding ClojureScript from a purely server side project. There you definitely want all versions excluded to keep your uberjar smaller.

luke19:01:54

@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.

dominicm19:01:38

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.

grounded_sage19:01:39

@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.

bhagany19:01:52

@grounded_sage and the file is in a tmp dir?

bhagany19:01:16

what's the error?

grounded_sage19:01:56

@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.

bhagany19:01:33

alright. that doesn't ring any bells for me.

grounded_sage20:01:07

@bhagany

(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!)))))

grounded_sage20:01:03

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

bhagany20:01:11

I think it would error the other way because in-file isn't in tmp

grounded_sage20:01:30

That structure is basically the same as the example given for filesets in boot docs

bhagany20:01:56

okay... but boot wouldn't like it if you were to write to a non-tmp directory

grounded_sage20:01:27

It writes to here doesn't it (io/file tmp out-path)?

bhagany20:01:44

that's putting out-file in tmp

bhagany20:01:59

but your example from earlier was appending to in-file

grounded_sage21:01:53

Trying to do a mutation outside of a tmp-dir

grounded_sage21:01:12

str is probs the simplest solution then

bhagany21:01:12

at least, that's what I think. I don't believe I've ever tried it 🙂

bhagany21:01:24

yes, I'd do it the way you worked out, I think

richiardiandrea23:01:17

@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