Fork me on GitHub

I’m using the Heroku buildpack for boot, and am running up against the problem listed in the “Troubleshooting” section: > You may get into situation where some wrong version of boot executable or the framework is cached in the app’s build cache. You can purge this cache like so… Does anyone know if there is a way to work around this, so that builds can be automated (by CircleCI etc)?


Hmm, my colleague just found a fix, involving a slight problem with grep.


Is it possible to turn a boot cache filepath back into it's original path? Programatically, not by hand. The cljs compiler puts absolute paths into metadata, which makes jump to source very inconvenient with boot.


Uhm, I read in #cider as well..I think I patched the :file meta in the compiler and it should be configurable (boot can pass its own thing). However, I don't remember too much of it now..I'd raise an issue in boot-cljs...


@richiardiandrea do you remember much about your patch, e.g. how it was configured?


I went back a bit and I was remembering incorrectly, basically the :file meta is returned from the *load-fn* is only for cljs-in-cljs.


it is hard to keep track of work done in the compiler, it moves fast 😄 Probably better to start with Juho, he knows better where the problem can be...then escalate to #cljs-dev 😄


@danielcompton that seems risky and more trouble than it's worth to speed up CI. Do you absolutely depend on fast turn-around times for CI?


I mean, I have a piece of code which subpaths the path until it finds the longest resource & uses that. I have no idea if it's more appropriate or not...


@pesterhazy it definitely would be risky with leiningen, I assumed that boots architecture would be more amenable to caching outputs safely?


But I don’t know much about boot


usually the caches don't outlive the boot process I think


There is a cache which is persistent now


@dominicm what are they used for?


@pesterhazy currently I think the aot/uber task uses it to cache something related to ripping apart dependencies.


ok, but I think you'd need some pretty strong guarantees that the caches won't need to be invalidated. Part of the appeal of boot is that there's no boot clean (and there doesn't need to be).


Agreed. Dependencies are immutable, so not a problem there. You can also hash files as appropriate.


I guess you could come up with something like AOT for code of cljs dependencies


but lots of unknowns there of course


I believe @thheller had an approach for doing safe caching of cljs based on the dependencies & such.