This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-09
Channels
- # alda (9)
- # announcements (1)
- # beginners (6)
- # boot (140)
- # cbus (2)
- # cider (27)
- # cljs-dev (19)
- # cljsrn (17)
- # clojure (104)
- # clojure-art (1)
- # clojure-brasil (5)
- # clojure-colombia (2)
- # clojure-russia (146)
- # clojure-sg (3)
- # clojurescript (64)
- # clojurex (1)
- # cursive (17)
- # data-science (22)
- # datomic (41)
- # editors-rus (5)
- # events (1)
- # hoplon (61)
- # ldnclj (35)
- # lein-figwheel (1)
- # off-topic (1)
- # om (119)
- # onyx (214)
- # re-frame (3)
- # reagent (13)
- # robots (5)
- # slack-help (1)
- # yada (17)
@micha: ^ this seems to be the cause (bisected it). Got to sleep now, later!
@micha: yeah that’s indeed strange but if you look at the diff for the branch there is very little change: https://github.com/boot-clj/boot/compare/master...7f566df < before reversing https://github.com/boot-clj/boot/compare/boot-builds-boot2 < after reversing
also to add more confusion: all of this is built with 2.4.2 i.e. the code that does the newPod changes can impossibly be used by boot during compilation
how do you mean install fake version?
calls it via aot task
there’s a compile pod …(?)
but why does it work before the reverted change?
if a namespace is already loaded when you call compile to aot, i think it uses the one that's loaded
the jars definitely worked as far as I can tell
oh right, now that makes sense
essential conclusion is we don’t aot boot pod stuff? could we make pods that don’t have boot.pod loaded?
and boot.App as well perhaps
I need to sleep. Let me know what you think is best to fix this/move forward.
Hi. I just tried to run a bootified clojure script which uses a shebang like
#!./boot
instead of /usr/bin/env boot
and this fails with an error message saying that the script-name is not a task. Does boot behave differently?Easily shipping something to be run somewhere else. Just check in the boot Loader as
boot
and then after a checkout of only two files (boot + the .clj file) one would be able to run it.Yes, sure. It is for a really quick prototypish thing that I want to run on a temporary EC2 machine on which I don't want to install any stuff...
Yeah, I know. Just as boot itself does. Compare that to the effort, gradlew makes to set up the environment. 😉
@micha regarding the aot thing: it's not about aot but having the boot.pod ns on the classpath when the compile pod is being created. It overrides the namespace as it is shipped by the invoked boot.
@martinklepsch: yeah, i think we want to eventually not do AOT when we build the boot jars
@micha: while the issue occurs during AOT it’s really not AOT specific. any task that redefines namespaces to use updated functions from boot/base will fail when ran with a version of boot/base that doesn’t have those updated functions
I guess there’s no way we can replace an already loaded version of boot.App
with one we take from a dependency added via set-env!
right?
@martinklepsch: i don't think there is a way to do it without a lot of fanciness
I’m having trouble using (sift :move …)
to move a file that is nested many directories deep to a root directory. It’s just renaming the file at the deep directory level.
@juhoteperi: could boot-reload automatically resolve the websocket host name from the current (.-location js/window)
to enable remote reloading without having to hard-code an IP?
here’s the fileset object before sifting
META-INF
└── resources
└── webjars
└── font-awesome
└── 4.4.0
└── css
└── font-awesome.min.css
META-INF
└── resources
└── webjars
└── font-awesome
└── csss
└── font-awesome.min.css
@pandeiro: No need for host name as boot-reload by default uses relative url to open WS connection
it's doing
(cloojure.string/replace "META-INF/resources/webjars/font-awesome/4.4.0/css/font-awesome-min.css" #"4.4.0/css/(.*)" "csss/$1")
oh ok. It’s working now. Thanks for the the internal code sample, that demystifies it for me
i’m trying to build a boot task to prerender js (i’m basically egregiously copying the boot-hoplon prerender
task). i have some html files that i have added to (set-env! {:resource-paths #{…}})
, but i noticed that the cljs
task is not copying them into the same dir as the js output, which causes phantomjs
to fail as it can’t find the js files referenced in the html.
@esp1: do you have a cljs.edn?
it can be used to configure builds https://github.com/adzerk-oss/boot-cljs#multiple-builds
@esp1: the files in resource paths will just be moved to the fileset relative to the dirs they’re in
i’m looking over the boot-cljs
docs now… it seems like it is for configuring the cljs compilation, but in my case i’m just trying to force the html files to be copied into the same dir as the js output of the cljs
task. i did notice that the hoplon
task is creating blah.html.cljs.edn
files, but i’m trying to figure out what that’s for
@esp1: you just need to move files into the right place in your directory structure
@esp1: is your project on github by any chance?
the html files in the resource paths do get moved to the output directory just fine, and they wind up in the right place, but the phantomjs task is referencing them from the .boot/cache/tmp
dirs, and at that point the html files are not present alongside the js
@martinklepsch: no, it’s not on github right now. i could try to publish it but it’s kind of a mess atm
if you try to run it directly from the fileset referencing files by their relative paths might not work as you would expect
actually, has anyone built a prerender boot task for anything other than hoplon? that’s ultimately what i’m trying to do
@pandeiro: yes, but i’m trying to do the prerender as part of a boot pipeline and have it spit out the prerendered html at the end, just like the hoplon prerender
task
(comp (watch) (serve :port 8080) (cljs) (execute-phantom-script :port 8080))
<- something like this would be my approach
i don't know if it will help at all but i did a little project that uses boot to prerender server-side
i don't think it's a drop-in solution but there may be code there in the defcljs
macro or thereabouts that could help
if i add an html file in a resource directory via (set-env! {:resource-paths #{“resource-dir"}})
, then it does *not* get added to the same .boot/cache/tmp
dir as the js output of the cljs
task. However if I create a (tmp-dir!)
, add the html file to it and then add the tmp-dir to the fileset via add-resource
, then it shows up alongside the js when the cljs
task is run.
so it seems like paths added via the env
and via add-resource
are handled differently...
I've had some problems with something related recently actually (https://github.com/pandeiro/boot-http/issues/29)
I did update https://github.com/boot-clj/boot/wiki/Deploying-with-Boot minimally to match the new GPG stuff
Could use improvmenets, and the new GPG implementation could use lots of testing
@juhoteperi: what exactly would be good to test there, if I just continue using env variables for my clojars credentials does this use “the new code”?
@martinklepsch: Using bootlaces and env variables still uses the new signing implementation, but it doesn't use new credentials stuff
for new credentials stuff I use the $BOOT_HOME/credentials.clj.gpg
approach?
$BOOT_GPG_BINARY
mentioned on the wiki page seems to be just $BOOT_GPG
I’m not getting a nullpointer exception here https://github.com/boot-clj/boot/blob/c49e69c417f1d2be4c4f536cb635c81f2d23050c/boot/aether/src/boot/aether.clj#L87
Reason was that the chosen :repo
(via push task) wasn’t in (get-env :repositories)
deployed this with boot-HEAD https://clojars.org/org.martinklepsch/cc-set
When supplying :gpg-sign true
I get messages like "You need a passphrase to unlock the secret key for.. ” but no prompt to enter such password — is that a bug?
Also how can I detect if a clojars artifact is properly signed?
snapshots are not signed
sounds like a bug, but could also be caused by your gpg settings
if you run just gpg --sign random-file
from terminal, does it ask for password?
huh it prints the same message but signing seems to work
also decrypting seems to work fine, maybe this message is just how my gpg command behaves