This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-29
Channels
- # aws (1)
- # beginners (65)
- # boot (400)
- # cider (19)
- # clara (2)
- # cljs-dev (29)
- # clojure (127)
- # clojure-chicago (2)
- # clojure-conj (1)
- # clojure-dev (12)
- # clojure-russia (156)
- # clojure-sg (6)
- # clojure-za (1)
- # clojurescript (193)
- # core-async (23)
- # datomic (91)
- # editors (4)
- # editors-rus (1)
- # events (1)
- # hoplon (3)
- # jobs (1)
- # ldnclj (6)
- # leiningen (3)
- # nginx (3)
- # off-topic (5)
- # om (93)
- # onyx (10)
- # re-frame (11)
- # spacemacs (1)
- # testing (2)
- # yada (5)
Oh of course, setting :target-path to “src” works, though I need to remove my json files before outputting the code
a macro that sets things, runs the body, then unsets the things back to what they originally were
this will work with directories, because boot doesn't actually add your :source-paths or :resource-paths to the classpath
:resource-paths is the set of paths from which files are copied into boots own internal directories
so if you remove a directory from there it will remove those files from boots internal dirs
boot should come with a warning that if you’ve only ever used lein you probably don’t really grok the classpath and that will bite you 😉
you don't need to know anything about the classpath unless you want to do things you can't even do with lein
Hey guys. I am setting up a new Ubuntu 15.10 desktop and am installing boot on it. I have installed boot several times without any problems, however, this time I am getting a very bizarre error. When I try and run boot
in an arbitrary directory I get this stack trace: http://pastebin.com/A9WizY92. This is the output of java -version
:
openjdk version "1.8.0_66-internal"
OpenJDK Runtime Environment (build 1.8.0_66-internal-b17)
OpenJDK 64-Bit Server VM (build 25.66-b17, mixed mode)
I have no idea what this error could be caused by and there are no results in Google about anyone with a similar error. Any ideas?Yeah that did it. Must not have picked up that dep the first time around and kept using the same home dir. Thanks 😃
So I want to bump the nixos boot vsn to support 2.4.2
but I see there isn't any boot.sh
released. Also when running 2.2.0
I get a message Please download latest Boot binary:
is this necessary? Surely if I want to run 2.2.0
that's exactly the version I want to run.
Why kill my process cause it's an older version? https://github.com/boot-clj/boot/blob/4a20c74b814aab82f3a04706f0116f1857149241/boot/core/src/boot/main.clj#L93-L94
I've changed my private nixpkgs repo to support the boot.jar instead of the boot.sh. I think this'll be more stable in the long run.
@sjm can you share your nix pkg definition? Just curious :)
@jfntn: why do you want to write the generated files to source dirs? Do you want to check them into the repo?
@sjm: also what's the output of boot -V
in that 2.2.0 Project? In general the new binary is even lighter and able to run many older versions of boot, including 2.2.0
did I hear nix?
Hahaha
@pesterhazy: do you use nix on your work laptop btw?
On the boot cljs repl in a re-frame/reagent project when I reference a symbol, for example product-form.core/mount-root
, I get a warning WARNING: Use of undeclared Var product-form.core/mount-root at line 1 <cljs repl>
after which it proceeds to print the symbol's value to the repl. What's the warning about?
pesterhazy: martinklepsch here's the default.nix
{ stdenv, fetchurl, jre }:
stdenv.mkDerivation rec {
version = "2.4.2";
name = "boot-${version}";
builder = ./boot_builder.sh;
src = fetchurl {
url = "";
sha256 = "01pw879s4f2bv5nwljapsfrddnz3295vkmdrm5dnl874qh5dmmjk";
};
inherit jre;
}
and the boot_builder.sh
source $stdenv/setup || exit 1
mkdir -p $out/bin
cp $src $out/bin/boot.jar || exit 1
cat > $out/bin/boot <<EOF
#! $SHELL
export JAVA_HOME=$jre
$jre/bin/java -jar $out/bin/boot.jar \$@
EOF
chmod a+x $out/bin/boot || exit 1
@martinklepsch: I do , but not extensively, only for a few things
it messes with curl
's SSL certs, which is annoying
we have SO MANY problems with gem, npm, cocoapods and pip, however, that nix would fix
@sjm: I’d suggest using the boot.sh
files that come with releases they properly use BOOT_* env vars etc
I just don't want to confuse people any further by introducing another Meta-package-manager
martinklepsch: Okay but boot.sh needs to be released first - and that blasted error prevents me from developing otherwise. So make do with what's available
@sjm: you can use boot.sh
from 2.4.0 — if it’s not added to later releases that means it’s unchanged
Admittedly that is confusing and we’re going to fix it soon
ah wait... I recall there was a catch in the nix expressions. Nevermind. it's working now, i'll update my expressions when boot.sh becomes available
if you do export BOOT_VERSION 2.2.0 && boot -V
what does that say? should use 2.2.0 properly
(even when ran with the boot.sh from 2.4.0 — new binaries will be released under different versioning scheme to avoid confusion as they change very rarely)
@sjm: the reason to kill the process is because it's too much work to try to guarantee compatibility between release version of boot in maven and all previous versions of boot.jar
$ export BOOT_VERSION=2.2.0 && boot -v
Acquired java.util.concurrent.Semaphore@3d0b6ed3[Permits = 0]...
Released java.util.concurrent.Semaphore@3d0b6ed3[Permits = 1]...
Boot App Version: 2.4.2
Boot Lib Version: 2.2.0
Clojure Version: 1.7.0
Clojure name: org.clojure/clojure
yeah, usually
I'm trying to debug why adzerk.boot-cljs-repl
is not getting injected into the :require
vector of my build file
@martinklepsch: cool, are you still on 0.1.9?
no snapshot
yeah, should probably update that -.-
(pr welcome :P)
I’m lost, get it working where?
Usually reloading and sometimes repl when I’m experimenting how to do stuff exactly
sorry no i meant hacking on lein-template stuff... 1. make change, 2. lein install, 3. lein new tenzing foo, 4. cd foo && boot dev
ah yeah, basically that’s it
there’s a flag for that in lein
lein new —snapshot or something
seems like you need a different :asset-path
per build... boot-cljs doesn't append the app.out
portion once you overwrite :compiler-options {:asset-path ...}
It says it's adding adzerk.boot-cljs-repl
to :require
, but it doesn't seem like it's getting there. The adzerk/boot_cljs_repl.cljs
file is never getting loaded in my app. 😕
and it adds it to the cljs.edn file you’re expecting it to add to?
for some reason when I remove boot-reload, my main.cljs.edn
stops showing up in the target dir
(with-pre-wrap fs (println (slurp (tmp-file (get-in fs [:tree “…cljs.edn”])))) fs)
something like that
it’s where the fileset stores references to tmpfiles and their paths
keys are the paths relative to :source-paths
etc
if main.cljs.edn
is in the root of one of my :source-paths
, then it would just be [:tree "main.cljs.edn"]
?
that's a cool utility task for inspecting the state of a file at certain points in the pipeline, thanks @martinklepsch 👍
I hope it helps
does the file exist?
Try inserting that task after the repl and after the cljs task
maybe the cljs task is overwriting the cljs.edn file because the handling for the default .cljs.edn file is somehow borked
yeah I mean something like (repl) (inspect) (cljs) (inspect)
The repl task needs to come before the cljs task in case that’s not clear
wow yes, so at the inspect
after boot-cljs-repl, it's there... at the inspect
after boot-reload, it's not anymore
now this is weird: when i comment out reload, the inspect
right before the cljs task goes back to the original main.cljs.edn
(easy to see as it still has whitespace and comments that are in the source main.cljs.edn
)
@martinklepsch: any idea based on the above where the fix needs to be implemented? something in boot-cljs-repl probably? like the version of *.cljs.edn
it is modifying is not getting added back to the fileset in a "durable" way?
tl;dr of above is -- works if cljs-repl
is right before cljs
task, but not otherwise
I’d suspect the culprit in boot-reload, (repl)
adds the right stuff but somehow boot-reload doesn’t use it?
no, even with boot-reload out of the picture, boot-cljs-repl's modifications to .cljs.edn files are lost if it is not right before the cljs task
ahh, misread then
we are talking about boot-cljs-repl master?
i'm looking at boot-cljs-repl -- this seems right to me, but... https://github.com/adzerk-oss/boot-cljs-repl/blob/master/src/adzerk/boot_cljs_repl.clj#L186-L194
like watch
is re-syncing the fileset with :source-paths
stuff or something i imagine
that could be it indeed
maybe it would be interesting to have the watch task merge the fileset it gets with the new fileset it gets by watching :source-paths
and :resource-paths
— would make sense to me after a quick thought
that sounds good. The READMEs should get some more love in general
@micha: I hit a mystery when boot-cljs-repl
seemed it wasn't doing its injection if I put it before the watch
task
@micha: the watch task resets the fileset but could potentially merge the new fileset with the one it got itself
this also solves some stuff like not doing the cljs edn injections over and over again
yeah that's the idea of the watch task, that it resets the fileset to the version it started with
oops 😄
thanks a bunch for the debugging help @martinklepsch -- super happy I got my repl back
always happy to & thanks for the tenzing PR
i noticed that github serves boot.sh from the releases page with a content-type of text/plain or something
wget works to download it, but curl gets confused and munges it thinking it's plain text
@micha: travis downloads it with curl and it works fine?
sounds like something not following redirects?
what’s the best way to verify that something like -Djavax.net.ssl.trustStore=$PWD/truststore/cacerts
has been properly set?
I expected it to show up in (System/getProperties)
but it doesn’t — does that mean something’s wrong?
how about (System/getProperty "javax.net.ssl.trustStore")
?
i tested with BOOT_JVM_OPTIONS="-Djavax.net.ssl.trustStore=foo" boot repl -e '(do (println (System/getProperty "javax.net.ssl.trustStore")) (System/exit 0))'
@micha: Y U NO USE BOOT
your argument is invalid
We don’t either.
I was also thinking maybe boot-bin
is a more appropriate name?
@micha: yeah for the repo. boot.sh seems unix specific while it’s also for windows...
minor thing, just something that occurred to me
Gotta go. Talk later!
https://github.com/boot-clj/boot-bin/releases/download/latest/boot.sh is what we can link to from the main boot readme
we can update that release to replace the boot.sh and boot.exe with the latest thing whenever we make a new one
hey this looks great, thanks, though I must admit speaking from "The Nix Way"™ the idea of boot updating itself without the consent of nixos is questionable at worst.
maven, yes, but if boot is packaged as a nix package, it should be immutable
right
it just means that it may work one day, but not work the next day
but I guess that's partly to be expected for a package manager (which depends on a network connection anyway)
so you could set BOOT_HOME to like /opt/boot or whatever the recommended thing is in nixos
that would be a good option I think
your package could even include all earlier versions of boot, maybe via dependencies or something
right 😐
the nix and maven ecosystems are somewhat orthogonal
which isn't too bad in my view, as maven works well
it's not as urgent to nix-ify clojure tools/libraries as it is with other ecosystems (python, ruby, node)
can you package boot as a single uberjar?
i.e. without requiring further dependencies to be downloaded on the first start?
not boot, you'd need to package boot + your project and all of its dependencies aas an uberjar
well for deployment you can always create an uberjar, so you don't need boot at all
(on the prod servers)
for me, uberjars are like docker containers, but nicer
docker is not as popular among nixers
but I see the value in mixed environments
just not in a jvm shop
@micha: do you guys pre-compile the frontend into the docker image as well, or save that for when the container is run?
we just make sure that the frontend isn't updated to a new version that's not compatible with the backend, of course
so there's a server somewhere that does the frontend build (like via webhook from git or something) and ships it off to S3 or wherever on command?
ah ok, yeah, it's not hard, i just can't figure out when is the right part of the process to do it in
we had our CI machine doing it but since we don't deploy every day it seemed simpler to just do it manually
yeah that sounds difficult; right now we're aiming to just use nginx on a regular linux server
the thing i want to avoid is: Hit 'deploy' and wait 3:30 for the frontend to build before it comes up
you could also just do something like this for a couple minutes though - http://contemporary-home-computing.org/still-there/fullsize/geocities/uc.png
@micha I'm using http://github.com/fractalide/boot-nix to create a 'custom tailor made .m2 folder' for all project specific dependencies. I honestly don't like swapping out jars under me. So during development I use normal mvn but when it comes to deployment I prefer something like boot-nix to build an uberjar. Ideally... if it were the nix way, the nix people would have at the src of every jar and compile each one.
Infact you cannot build a clojure nixpkg the nix way without something like boot-nix because during build time you literally have no network access. You also have no access to a build user environment (as you are nobody
) for mvn to create a .m2 folder. The reason why I like this approach is that software doesn't suddenly stop working on me cause some dude commited a bug in a transitive dependency somewhere.
I’m unable to compile some CLJS tests with boot-cljs, getting this error: ERROR: Only :as and :refer options supported in :require / :require-macros; offending spec: [cljs.test :refer-macros [deftest is testing run-tests]]
@micha: re boot-bin versioning: 1.0.0 might be weird with homebrew and other packages — downgrading from 2.4.0 to 1.0.0
@jfntn: Is that form inside (:require-macros)? If so, you should use :refer instead of :refer-macros
@juhoteperi: the entire form is (:require [cljs.test :refer-macros [deftest is testing run-tests]])
@jfntn: Looks correct. What does the complete ns form look like?
never seen multiple :require
s — tried w/o them?
@jfntn: Not sure, but I don't think multiple :require
s will work
weird, multiple requires totally works in clj
Clj ns form supports many things that Cljs ns form doesn't support and never will
of them though, this seems like one that should work
definitely not worth pursuing though, as ns is already one of clj's most epic bikesheds
Java is so frustrating 😄 Tried using this and works but now throws an exception that “Registration failed.” and I have no clue how to get additional information: https://github.com/zero11it/acme-client/blob/master/src/main/java/it/zero11/acme/Acme.java#L166 FML.
@martinklepsch: what'sthe last version of boot-clj in homebrew?
2.4.0 I think
that's the initial version it will install of boot anyway, if you run it for the first time
yes, I think that’s better. then versions can diverge after that. Can still confuse but well...
go for it 👍
set -x
is like export
and set -e
unsets an env var
fish shell stuff. I’ve you’ve never tried fish you should! I bet you’d like it
what was that?
That makes sense but then they also shouldn’t be in that file
in what way shit went down? I never used more than my own config, grew tired of keeping up with shell plugin blabla stuff. Fish isn’t POSIX compliant though so that is a bit of a switch.
Are we talking about DMCA MIT stuff?
the output of boot -V is defined in the loader?
How about boot -E
printing all environment configuration stuff and keeping boot -V
as it has been before only printing version info?
or something similar?
or we just prepend #
to the lines that won’t have effect
Anyone had a chance to give the boot-builds-boot branch a try? :