Fork me on GitHub
#boot
<
2015-10-29
>
jfntn00:10:09

Oh of course, setting :target-path to “src” works, though I need to remove my json files before outputting the code

jfntn00:10:01

Is there a way to have task-local env values other than pre/post setters?

micha01:10:27

jfntn: you can call set-env! whenever you like

micha01:10:39

but the env is global, there is no way around that

micha01:10:46

the JVM has only one classpath

micha01:10:15

you can do a thing like clojure does with thread local bindings

micha01:10:37

a macro that sets things, runs the body, then unsets the things back to what they originally were

jfntn01:10:47

yeah that’s what I was thinking

micha01:10:09

this will work with directories, because boot doesn't actually add your :source-paths or :resource-paths to the classpath

micha01:10:23

it copies files into its own managed temp dirs

micha01:10:55

so if you do like (set-env! :source-paths #(disj % "src")) for example

micha01:10:09

all the files from the src dir will be removed from the classpath

micha01:10:22

but the src directory itself never was on the classpath

micha01:10:31

only copies of the files it contains

micha01:10:38

if that makes any sense

micha01:10:53

with :dependencies there is nothing you can do

micha01:10:05

once a jar is loaded in a classloader you can't remove it

jfntn01:10:31

ok cool that makes sense

micha01:10:54

you might want to consider pods

jfntn01:10:58

would removing a dir from :resource-paths work too?

micha01:10:19

that's how you get scoped runtime environments

micha01:10:45

:resource-paths is the set of paths from which files are copied into boots own internal directories

micha01:10:50

which are on the classpath

micha01:10:22

so if you remove a directory from there it will remove those files from boots internal dirs

micha01:10:28

which will remove them from the classpath

jfntn01:10:45

ok that makes sense

jfntn01:10:31

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 😉

micha02:10:54

you don't need to know anything about the classpath unless you want to do things you can't even do with lein

micha02:10:25

like if you stick to the stuff in adzerk/bootlaces you'll never see a classpath simple_smile

kenny02:10:47

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?

micha02:10:09

@kenny: can you paste the md5sum of boot.sh please?

kenny02:10:57

@micha: 9dd9f0ae594b1658fe79477ceb492289

micha02:10:05

hm that's fine

kenny02:10:31

I repeated the install process several times now to no avail.

micha02:10:20

can you try doing rm -rf ~/.boot

micha02:10:33

assuming you don't have BOOT_HOME set to something else

kenny02:10:36

Yeah that did it. Must not have picked up that dep the first time around and kept using the same home dir. Thanks 😃

micha02:10:56

ah yes this is a but that will be fixed soon

micha02:10:08

PR is in, just need to merge it and deploy

isaac04:10:01

My cider jump to definition will navigate to cache file when connect boot repl?

sjm05:10:56

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.

sjm06:10:49

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.

martinklepsch07:10:48

@sjm can you share your nix pkg definition? Just curious :)

martinklepsch07:10:35

@jfntn: why do you want to write the generated files to source dirs? Do you want to check them into the repo?

martinklepsch07:10:13

@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

pesterhazy08:10:38

did I hear nix?

martinklepsch09:10:08

@pesterhazy: do you use nix on your work laptop btw?

mbertheau10:10:25

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?

sjm11:10:18

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;
}

sjm11:10:45

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

pesterhazy11:10:51

@martinklepsch: I do , but not extensively, only for a few things

pesterhazy11:10:09

it messes with curl's SSL certs, which is annoying

pesterhazy11:10:53

we have SO MANY problems with gem, npm, cocoapods and pip, however, that nix would fix

martinklepsch11:10:07

@sjm: I’d suggest using the boot.sh files that come with releases they properly use BOOT_* env vars etc

pesterhazy11:10:25

I just don't want to confuse people any further by introducing another Meta-package-manager

sjm11:10:10

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 simple_smile

martinklepsch11:10:07

@sjm: you can use boot.sh from 2.4.0 — if it’s not added to later releases that means it’s unchanged

martinklepsch11:10:22

Admittedly that is confusing and we’re going to fix it soon simple_smile

sjm11:10:26

martinklepsch: got the same error with 2.4.0

sjm11:10:26

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

martinklepsch11:10:50

if you do export BOOT_VERSION 2.2.0 && boot -V what does that say? should use 2.2.0 properly

martinklepsch11:10:32

(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)

micha11:10:35

@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

micha11:10:56

now we release a boot.jar with every boot release

micha11:10:15

so we can safely make changes to either one, or both

sjm11:10:30

ah gotcha

micha11:10:39

this way will be way more stable

sjm11:10:50

$ 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

sjm11:10:05

yeah it worked.

micha11:10:22

yeah the new regime only applies after 2.4.0

sjm11:10:31

micha: okay thanks for the clarification - it sounds reasonable.

micha11:10:42

it'll download the correct version of boot.jar for earlier boot versions

micha11:10:52

it has a hardcoded map of versions

micha11:10:56

internally

micha11:10:05

for all the previous releases

sjm11:10:40

anyway thanks for the clarification chaps, much appreciated

pandeiro12:10:23

Anyone using boot-cljs-repl?

pandeiro12:10:58

I'm trying to debug why adzerk.boot-cljs-repl is not getting injected into the :require vector of my build file

pandeiro12:10:10

@martinklepsch: cool, are you still on 0.1.9?

pandeiro12:10:44

I noticed tenzing has adzerk.boot-cljs 0.0.3308-0 and adzerk.boot-cljs-repl 0.1.9

martinklepsch12:10:55

yeah, should probably update that -.-

martinklepsch12:10:02

(pr welcome :P)

pandeiro12:10:04

i tried, it needs some tweaking though

pandeiro12:10:11

ok, i think i can figure it out...

pandeiro12:10:28

but i was hoping to figure out this missing injection issue

pandeiro12:10:43

let me see if i can get it working there

pandeiro12:10:16

how do you usually develop on that? make changes, re-generate project, test?

martinklepsch12:10:18

I’m lost, get it working where?

martinklepsch12:10:51

Usually reloading and sometimes repl when I’m experimenting how to do stuff exactly

pandeiro12:10:03

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

martinklepsch12:10:20

ah yeah, basically that’s it

pandeiro12:10:35

it's weird, lein won't pick up a new snapshot version of the template

pandeiro12:10:43

had to overwrite 0.3.4 or whatever it is

martinklepsch12:10:02

there’s a flag for that in lein

martinklepsch12:10:10

lein new —snapshot or something

pandeiro12:10:50

huh, can't get it to add the :asset-path there... oh well

pandeiro12:10:05

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 ...}

pandeiro12:10:24

is :unified-mode still a thing in boot-cljs?

pandeiro12:10:54

cool PR submitted

pandeiro12:10:10

now i gotta figure out why boot-cljs-repl works there, but not here simple_smile

pandeiro12:10:34

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. 😕

martinklepsch12:10:14

and it adds it to the cljs.edn file you’re expecting it to add to?

pandeiro12:10:37

right, that's the question... hard to inspect that, any advice?

pandeiro12:10:58

for some reason when I remove boot-reload, my main.cljs.edn stops showing up in the target dir

martinklepsch12:10:02

(with-pre-wrap fs (println (slurp (tmp-file (get-in fs [:tree “…cljs.edn”])))) fs)

martinklepsch12:10:25

something like that

pandeiro12:10:35

what is :tree there?

martinklepsch12:10:06

it’s where the fileset stores references to tmpfiles and their paths

martinklepsch12:10:28

keys are the paths relative to :source-paths etc

pandeiro12:10:37

if main.cljs.edn is in the root of one of my :source-paths, then it would just be [:tree "main.cljs.edn"] ?

pandeiro12:10:09

that's a cool utility task for inspecting the state of a file at certain points in the pipeline, thanks @martinklepsch 👍

martinklepsch12:10:18

I hope it helps simple_smile

pandeiro12:10:40

yeah, sure enough, it's not getting injected...

martinklepsch13:10:04

does the file exist?

martinklepsch13:10:16

Try inserting that task after the repl and after the cljs task

martinklepsch13:10:50

maybe the cljs task is overwriting the cljs.edn file because the handling for the default .cljs.edn file is somehow borked

pandeiro13:10:21

oooh, yeah ok let me check that

pandeiro13:10:33

I am checking the state before the cljs task though

pandeiro13:10:42

between cljs-repl and cljs

martinklepsch13:10:39

yeah I mean something like (repl) (inspect) (cljs) (inspect)

martinklepsch13:10:07

The repl task needs to come before the cljs task in case that’s not clear

pandeiro13:10:35

yep got all that... i'm doing the inspect in several places now

pandeiro13:10:18

wow yes, so at the inspect after boot-cljs-repl, it's there... at the inspect after boot-reload, it's not anymore

pandeiro13:10:41

now this is weird: when i comment out reload, the inspect right before the cljs task goes back to the original main.cljs.edn

pandeiro13:10:51

like it is getting a previous version somehow

pandeiro13:10:19

(easy to see as it still has whitespace and comments that are in the source main.cljs.edn)

pandeiro13:10:42

i'm checking what happens if i put cljs-repl right before the cljs task

pandeiro13:10:57

yep, it works if i do it that way

pandeiro13:10:54

@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?

pandeiro13:10:20

tl;dr of above is -- works if cljs-repl is right before cljs task, but not otherwise

pandeiro13:10:32

fwiw, boot-reload does not have this problem

martinklepsch13:10:54

I’d suspect the culprit in boot-reload, (repl) adds the right stuff but somehow boot-reload doesn’t use it?

pandeiro13:10:43

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

pandeiro13:10:56

i tested commenting out boot-reload entirely

martinklepsch13:10:56

ahh, misread then

martinklepsch13:10:52

we are talking about boot-cljs-repl master?

pandeiro13:10:05

maybe i got it.

pandeiro13:10:23

cljs-repl would need to be after the watch task???

pandeiro13:10:44

like watch is re-syncing the fileset with :source-paths stuff or something i imagine

pandeiro13:10:15

i had it like (comp (dev-repl) (watch) (reload) (other-stuff) (cljs))

pandeiro13:10:22

where dev-repl wraps cljs-repl

martinklepsch13:10:28

that could be it indeed

pandeiro13:10:36

makes sense i guess

pandeiro13:10:52

or should the watch task handle a pre-existing fileset?

pandeiro13:10:33

testing one more time to make sure that's the issue

pandeiro13:10:21

yep, seems so

martinklepsch13:10:27

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

pandeiro13:10:53

is there any reason it shouldn't do that?

pandeiro13:10:28

maybe @micha will weigh in; i don't understand all the ramifications of that

pandeiro13:10:48

meantime maybe i will PR a note to the boot-cljs-repl README warning about that

pandeiro13:10:05

good morning simple_smile

micha13:10:20

what's the thing with the watch task?

martinklepsch13:10:25

that sounds good. The READMEs should get some more love in general simple_smile

pandeiro13:10:07

@micha: I hit a mystery when boot-cljs-repl seemed it wasn't doing its injection if I put it before the watch task

pandeiro13:10:21

makes sense now but it was baffling me for a while

martinklepsch13:10:36

@micha: the watch task resets the fileset but could potentially merge the new fileset with the one it got itself

micha13:10:52

this is a bug

micha13:10:03

it should be doing that

martinklepsch13:10:30

this also solves some stuff like not doing the cljs edn injections over and over again simple_smile

micha13:10:59

yeah that's the idea of the watch task, that it resets the fileset to the version it started with

micha13:10:11

so it's definitely a bug if it doesn't do that

pandeiro13:10:43

yeah seems like the most obvious behavior

pandeiro13:10:56

should I create an issue?

pandeiro13:10:34

thanks a bunch for the debugging help @martinklepsch -- super happy I got my repl back simple_smile

martinklepsch13:10:00

always happy to & thanks for the tenzing PR simple_smile

micha13:10:21

i noticed that github serves boot.sh from the releases page with a content-type of text/plain or something

micha13:10:32

does anyone know how to change that?

micha13:10:56

wget works to download it, but curl gets confused and munges it thinking it's plain text

martinklepsch13:10:50

@micha: travis downloads it with curl and it works fine?

micha13:10:06

maybe i'm confused simple_smile

alandipert13:10:46

sounds like something not following redirects?

martinklepsch14:10:01

what’s the best way to verify that something like -Djavax.net.ssl.trustStore=$PWD/truststore/cacerts has been properly set?

martinklepsch14:10:25

I expected it to show up in (System/getProperties) but it doesn’t — does that mean something’s wrong?

alandipert14:10:25

how about (System/getProperty "javax.net.ssl.trustStore") ?

alandipert14:10:45

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))'

micha14:10:24

testing things, disregard

martinklepsch14:10:56

@micha: Y U NO USE BOOT lol

micha14:10:52

it's so small though

micha14:10:55

just one class

alandipert14:10:09

your argument is invalid

micha14:10:21

ok I USE BOOT

micha14:10:29

i don't know what i was thinking

martinklepsch14:10:27

We don’t either.

martinklepsch15:10:12

I was also thinking maybe boot-bin is a more appropriate name?

micha15:10:55

for the repo, you mean?

micha15:10:07

there we go

martinklepsch15:10:19

@micha: yeah for the repo. boot.sh seems unix specific while it’s also for windows...

martinklepsch15:10:15

minor thing, just something that occurred to me

martinklepsch15:10:39

Gotta go. Talk later!

micha15:10:54

ok so for version numbers, like for homebrew, nixos, etc

micha15:10:01

i was thinkign just 1.0.0

micha15:10:18

we can update that release to replace the boot.sh and boot.exe with the latest thing whenever we make a new one

micha15:10:03

in addition to the versioned releases for things like homebrew

sjm17:10:10

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.

micha17:10:56

sjm: what's questionable about it?

micha17:10:47

do you not use Maven in nixos?

micha17:10:52

and things like that?

pesterhazy17:10:19

maven, yes, but if boot is packaged as a nix package, it should be immutable

micha17:10:51

the boot binary is immutable

micha17:10:10

just like the java binary is

micha17:10:20

or google chrome

micha17:10:30

but it downloads things from the internet to work

micha17:10:52

you could avoid downloading anything if you want

micha17:10:04

you'd need to prepackage the boot.jar thing

pesterhazy17:10:06

it just means that it may work one day, but not work the next day

pesterhazy17:10:28

but I guess that's partly to be expected for a package manager (which depends on a network connection anyway)

micha17:10:32

you can make a nix package with the boot.jar

micha17:10:20

you just need to install it in BOOT_HOME/cache/bin/<version>/boot.jar

micha17:10:50

so you could set BOOT_HOME to like /opt/boot or whatever the recommended thing is in nixos

pesterhazy17:10:02

that would be a good option I think

micha17:10:33

your package could even include all earlier versions of boot, maybe via dependencies or something

micha17:10:46

ah nevermidn

micha17:10:08

you'd need to download all the maven stuff too

micha17:10:15

so it would gain you nothing

pesterhazy17:10:29

the nix and maven ecosystems are somewhat orthogonal

pesterhazy17:10:52

which isn't too bad in my view, as maven works well

micha17:10:10

yeah you'd need to make uberjars of everything otherwise

micha17:10:20

which is good for production

micha17:10:30

but kind of a hassle for development probably

pesterhazy17:10:57

it's not as urgent to nix-ify clojure tools/libraries as it is with other ecosystems (python, ruby, node)

pesterhazy17:10:09

can you package boot as a single uberjar?

pesterhazy17:10:33

i.e. without requiring further dependencies to be downloaded on the first start?

micha17:10:46

not boot, you'd need to package boot + your project and all of its dependencies aas an uberjar

micha17:10:05

because the first thing you want to do with boot is add dependencies to your project

micha17:10:16

so if you admit that then there is no benefit to the uberjar situation

micha17:10:24

because you're already assuming that maven works

micha17:10:53

what we normally do is deploy to docker containers

micha17:10:02

we download all the dependencies into the image

micha17:10:06

so it's immutable

micha17:10:26

for production deployment

pesterhazy17:10:29

well for deployment you can always create an uberjar, so you don't need boot at all

pesterhazy17:10:36

(on the prod servers)

micha17:10:44

we launch the application via boot

micha17:10:51

but that's not necessary

pesterhazy17:10:05

for me, uberjars are like docker containers, but nicer simple_smile

micha17:10:10

it's just an example of an uberized boot environment

micha17:10:48

i'm a huge fan of docker

micha17:10:53

it's saved my bacon

pesterhazy17:10:36

docker is not as popular among nixers

pesterhazy17:10:49

but I see the value in mixed environments

pesterhazy17:10:02

just not in a jvm shop

pandeiro17:10:41

@micha: do you guys pre-compile the frontend into the docker image as well, or save that for when the container is run?

micha17:10:03

yeah we prebuild everything

micha17:10:12

well we never have a front end in a server

micha17:10:16

we put that on the CDN

pandeiro17:10:25

Ah yeah sure, so it's part of a different flow?

micha17:10:29

the stuff in the docker container is just web services API

micha17:10:46

yeah but we do as much prebuilding as we can

micha17:10:53

when we make the docker container

pandeiro17:10:53

Makes sense... so the frontend part of the build doesn't use docker?

micha17:10:07

no, it's on S3 usually, and CloudFront

micha17:10:20

using CORS to talk to the backend web services API

pandeiro17:10:30

but the compilation step itself happens where? (if you can say :))

micha17:10:31

which we deploy to beanstalk in docker

micha17:10:47

oh we have a separate deployment

micha17:10:58

frontend and backend are versioned

micha17:10:06

so we can deploy them separately

micha17:10:45

we just make sure that the frontend isn't updated to a new version that's not compatible with the backend, of course

micha17:10:20

if we need to make a big change we'll use the 4 step process

pandeiro17:10:34

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?

micha17:10:43

we do it manually

micha17:10:50

it's just uploading some files to s3

pandeiro17:10:21

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 simple_smile

pandeiro17:10:27

but manual always works

pandeiro17:10:44

we just have a team that doesn't all know clojure/boot/etc

micha17:10:01

it's hard to make CI secure with automatic deploys to ASW

micha17:10:36

we had our CI machine doing it but since we don't deploy every day it seemed simpler to just do it manually

micha17:10:42

it's just typing boot deploy

pandeiro17:10:54

yeah that sounds difficult; right now we're aiming to just use nginx on a regular linux server

pandeiro17:10:22

the thing i want to avoid is: Hit 'deploy' and wait 3:30 for the frontend to build before it comes up

micha17:10:36

that's what's good about the CDN

micha17:10:53

we rename all the things in S3 to their sha

micha17:10:00

all except for index.html

micha17:10:03

naturally

pandeiro17:10:12

for cache-busting?

micha17:10:14

so we can just upload all the things to s3

micha17:10:18

well for immutability

micha17:10:24

we only overwrite index.html

micha17:10:29

so we don't need to invalidate the cache

micha17:10:43

and if someone is in the middle of loading the page it'll still work for them

micha17:10:52

because the old versions are still in the CDN

pandeiro17:10:59

yes that is cool

pandeiro17:10:12

and in the event of a breaking change, you handle that exceptionally i imagine

micha17:10:38

the client knows if the server version updates while it's in a session

micha17:10:46

and it'll tell the user they need to refresh

pandeiro18:10:18

ah ok, nice

pandeiro18:10:30

you could also just do something like this for a couple minutes though - http://contemporary-home-computing.org/still-there/fullsize/geocities/uc.png

pandeiro18:10:41

arguably more elegant

micha18:10:58

then we'd need to put it on our status page as downtime

micha18:10:24

the odds of someone getting the "you need to refresh" message is pretty slim

micha18:10:33

because we use the 4 step method

pandeiro18:10:13

very cool, thanks for the tour

sjm18:10:00

@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.

sjm18:10:32

Or you don't have to build an uberjar if you don't want to.

sjm18:10:30

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.

micha18:10:30

versioned artifacts protect you from the transitivedependency problem

micha18:10:52

like the dependency graph is deterministic

jfntn20:10:11

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]]

martinklepsch20:10:59

@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

juhoteperi20:10:42

@jfntn: Is that form inside (:require-macros)? If so, you should use :refer instead of :refer-macros

jfntn20:10:21

@juhoteperi: the entire form is (:require [cljs.test :refer-macros [deftest is testing run-tests]])

jfntn20:10:55

as per the clojurescript wiki

juhoteperi20:10:42

@jfntn: Looks correct. What does the complete ns form look like?

jfntn20:10:05

so the catch might be that it’s in a cljc file with reader conditionals

martinklepsch20:10:36

never seen multiple :requires — tried w/o them?

juhoteperi20:10:44

@jfntn: Not sure, but I don't think multiple :requires will work

jfntn20:10:11

Thanks guys that was the issue

alandipert20:10:08

weird, multiple requires totally works in clj

juhoteperi20:10:04

Clj ns form supports many things that Cljs ns form doesn't support and never will

alandipert20:10:03

of them though, this seems like one that should work

alandipert20:10:16

definitely not worth pursuing though, as ns is already one of clj's most epic bikesheds

martinklepsch21:10:23

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.

micha21:10:24

@martinklepsch: what'sthe last version of boot-clj in homebrew?

micha21:10:44

ok cool, i'll make 2.4.2 then?

micha21:10:49

in the boot-bin

micha21:10:34

that's the initial version it will install of boot anyway, if you run it for the first time

martinklepsch21:10:49

yes, I think that’s better. then versions can diverge after that. Can still confuse but well...

micha21:10:50

so maybe that makes some kind of sense

martinklepsch21:10:01

go for it 👍

micha21:10:07

okey dokey

micha21:10:50

i don't understand it

micha21:10:58

what is that demonstrating?

micha21:10:26

like what's the set -x and set -e stuff doing

martinklepsch21:10:08

set -x is like export and set -e unsets an env var

martinklepsch21:10:37

fish shell stuff. I’ve you’ve never tried fish you should! I bet you’d like it simple_smile

micha21:10:06

i saw their ohmyfish drama

martinklepsch21:10:13

what was that?

micha21:10:25

i dunno shit went down, apparently

micha21:10:31

what's the issue with that paste?

micha21:10:45

that boot doesn't apply settings from boot.properties BOOT_JVM_OPTIONS?

micha21:10:05

there's no way to do that, because the options need to be set before the JVM starts

micha21:10:14

same with BOOT_JAVA_COMMAND

martinklepsch21:10:16

That makes sense but then they also shouldn’t be in that file

martinklepsch21:10:40

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.

martinklepsch21:10:19

Are we talking about DMCA MIT stuff?

micha21:10:53

a lot of people at work use fish shell

martinklepsch21:10:52

the output of boot -V is defined in the loader?

micha21:10:12

nothing is defined in the loader except downloading boot.jar

martinklepsch21:10:13

How about boot -E printing all environment configuration stuff and keeping boot -Vas it has been before only printing version info?

martinklepsch21:10:22

or something similar?

micha21:10:53

sounds reasonable

martinklepsch21:10:04

or we just prepend # to the lines that won’t have effect

micha21:10:29

also a good idea

micha21:10:47

i like the first one i think

micha21:10:55

the minimal solution

micha21:10:00

we just need BOOT_VERSIon and BOOT_CLOJURE_VERSION i guess

micha21:10:28

perhaps a link to the wiki page about the env options

martinklepsch22:10:53

Anyone had a chance to give the boot-builds-boot branch a try? simple_smile :

jfntn23:10:59

How do you setup boot-cljs to compile a cljs library, that doesn’t have a main fn?