add-sync! doesn't sync files if they've been deleted in destination about boot HOT 15 CLOSED

Ah, I see now. This actually makes sense, because syncing of files happens before the final artifacts are emitted to the target directory. So the reason you see it the second time you run boot is because it's picking up stale files that are in the target directory from the previous run.

In general you don't want to ever reference the target directory in your code, because it's owned by boot. No user serviceable parts inside :) I think a better solution to your problem would be to make a task that calls boot.core/sync! to make hardlinks to a temp dir your task creates. Your task can then move the files in the temp dir to a different relative path. Does that make sense?

from boot.

Maybe I should start with the original problem. My thinking was that I use public/js/ as output path for Clojurescript and public/css for Garden. Now I want to serve these files via Compojure. Compojure provides files and resources route handlers for that (see route.clj).

It didn't feel right to just do (files "/assets" {:root "target/public"}) so I thought I could just sync whatever is in there into a toplevel dir (public).

I tried to figure this out for an eventual template want to create and I'm looking for an intuitive, potentially familiar solution so newcomers have an easy time and don't get confused.

from boot.

So the reason you see it the second time you run boot is because it's picking up stale files that are in the target directory from the previous run.

Is that a desirable property? That stale stuff might end up somewhere?

from boot.

So the reason you see it the second time you run boot is because it's picking up stale
files that are in the target directory from the previous run.

Is that a desirable property? That stale stuff might end up somewhere?

Definitely not. That's why you probably don't want to be doing anything from there directly. (Some read-only type interaction is okay, like for example you might start a local web server with the target dir as the webroot. That's okay since it's not modifying anything or persisting anything based on what's in there.)

from boot.

So does that mean your recommendation is to just go with (files "/assets" {:root "target/public"})?

from boot.

I just realized there is a heinous bug in boot :/ It's not correctly adding :rsc-paths to the classpath as it should do. This is a problem because I was about to say you should use resources instead of files for your Compojure routes, but that might not work now. The fix will be in shortly.

The reason why you want to use resources instead of files is because then you're working with relative paths, so you eliminate the direct reference to target.

from boot.

@micha that would work for static assets but my compiled .js doesn't get added to the classpath does it? (i.e. it's not in :rsc-paths; it ends up in target/)

That's the reason I thought there is no other way than using files.

from boot.

Actually, as a quick and somewhat dirty workaround you can start your Compojure app in a pod, like this:

(require '[boot.core :as core] '[boot.pod :as pod])
(let [env (update-in (core/get-env) [:src-paths] conj (core/get-env :tgt-path))
      pod (pod/make-pod env)]
  (pod/call-in pod
    `(my.namespace/compojure-app ~some-arg)))

This pod will have the target dir in its classpath, so you should be able to use resources in there.

from boot.

@martinklepsch actually it does. Anything emitted by a task to a tempdir ends up on the classpath for the rest of the tasks that follow it in the pipeline. (This is a slight simplification, but for your purposes it's correct.)

from boot.

I'm not blocked by this or anything, it's more of a quest for the simplest solution.

I wasn't aware of the fact that anything in target is added to the classpath but that way I could just not use that add-sync! statement and use Compojure's resources right?

I'll give that a spin in 20min

from boot.

Yes, try that. I think you should be mostly okay, and I'm fixing the :rsc-paths bug now.

The target dir is not actually in the classpath. But the temp dirs that tasks emit their files to are. These are the files that end up eventually in the target dir. Does that make sense? Basically the target dir is completely outside the build system.

from boot.

yep, think I understood what you mean

from boot.

That worked just as expected. Should've known that before, after you mentioned it made a lot of sense though :)

from boot.

@micha close at will.

from boot.

@martinklepsch Awesome, we did it!

from boot.