Fork me on GitHub
#boot
<
2018-06-26
>
borkdude14:06:54

I run into an issue with boot 2.8.0 where I’m loading a file from the resource to create queries with hugsql.

( "dre/db/html/query.sql")
This resolves to file:/Users/Borkdude/.boot/cache/tmp/Users/Borkdude/dre/DocSearch/app/gpu/-ueasqk/dre/db/html/query.sql, but when I change the file in my resources dir, the changes are not seen by hugsql. This cached file remains the same…

dominicm14:06:55

@borkdude what happens if you re-run io/resource?

martinklepsch14:06:06

@borkdude the classpath is static unless you use watch (in which case it gets updated). Using watch requires you to use a separate process for the repl client however..

borkdude14:06:31

we are already using watch, this workflow always worked until 2.8.0

borkdude14:06:00

I’m going to try what dominicm asked

dominicm14:06:24

Hmm, odd that it used to work. I suspect that there's probably something more here then, I've not been tracking commits to boot very closely recently, so there could be some good ideas on how to debug this in the changelog.

borkdude14:06:09

First time:

file:/Users/Borkdude/.boot/cache/tmp/Users/Borkdude/dre/DocSearch/app/h2a/-ueasqk/dre/db/html/query.sql
After edit:
file:/Users/Borkdude/.boot/cache/tmp/Users/Borkdude/dre/DocSearch/app/h2a/-ueasqk/dre/db/html/query.sql

borkdude14:06:28

(same cached file)

borkdude14:06:40

I’m going to try to reproduce this in a stripped down project

borkdude14:06:46

and then file an issue

borkdude14:06:06

hmm, tested in both versions with stripped down project and when I slurp the edited file I see the edits… so, don’t know what’s going on in my project 🙂

borkdude14:06:46

the file path doesn’t change though, in neither version

borkdude14:06:05

but that doesn’t matter to me, as long as the edits are visible

borkdude14:06:01

hmm, in my project I don’t see differences with slurp in 2.8.0, but I do with 2.7.2

borkdude15:06:10

This should be true

(= (slurp ( "dre/db/html/query.sql"))
   (slurp (io/file "src/dre/db/html" "query.sql")))

dominicm16:06:10

is it on any version?

borkdude16:06:20

no, only on 2.8.0

borkdude16:06:31

but I can’t reproduce it in a similar project

borkdude16:06:03

cljs reloading is working fine

borkdude16:06:25

I’m one step closer to the solution, commented out some composed tasks and now it works..

borkdude20:06:37

ok, found the issue, when I comment out this task then it works:

(deftask include-assets []
  (comp
   (sift :add-jar {'cljsjs/c3 #"cljsjs/c3/common/c3.min.css"})
   (sift :move {#"cljsjs/c3/common/c3.min.css"
                "public/css/vendor/c3/c3.min.css"})))
Not sure if anyone can make sense out of that.

borkdude20:06:47

it’s the (sift :move ...) that is causing this

dominicm20:06:38

Did that change in the latest release?

alandipert21:06:29

@borkdude thanks for finding that, can you please post your findings on a github issue if you haven't yet? it sounds like we should consider reverting the change

alandipert21:06:38

also if you could elaborate a little on your workflow there, that would be supremely helpful

borkdude21:06:32

I updated that issue with why I need this to work

alandipert21:06:44

that's great, thank you

borkdude21:06:46

I can imagine this would also break some people’s workflows when they were relying on evaluating clojure on save, like some reloaded workflows do?

borkdude21:06:28

personally I only evaluate manually (C-c C-k, or C-x C-e)

borkdude21:06:37

Fwiw, I had to change a bunch of stuff in our build.boots (we have 10 of them) related to using the newest s3-private-wagon which only works with boot 2.8.0, so reverting that is a bit painful. I’d rather not go back to 2.7.2 now, but I might if there isn’t a good workaround for this.

alandipert21:06:25

@borkdude perhaps i should just push 2.8.1 with the revert, and then we can discuss workflows and whether we want the change? without any pressure

borkdude22:06:01

seems like a good decision to me, considering it wasn’t known that this type of workflow would break?

borkdude22:06:43

and if there is a good alternative it can at least be announced as breaking in 2.8.2