Fork me on GitHub
#boot
<
2015-11-02
>
catonano08:11:42

Boot freshly installed, to "boot -h" replies "Please download latest Boot binary: https://github.com/boot-clj/boot#install"

martinklepsch08:11:20

@catonano: how did you install boot?

catonano08:11:34

I followed the instructions at the READ. me on github: I downloaded the boot.sh file, I moved it to "boot", I did "chmod a+x boot" and then "sudo mv boot /usr/local/bin/"

catonano08:11:08

there was no previous /usr/local/bin/boot

catonano08:11:23

and there wan no boot folder in .m2/repository

martinklepsch08:11:34

What’s the output of boot -V & do you have $BOOT_VERSION set or a boot.properties file?

catonano08:11:24

This is "boot -V" #https://github.com/boot-clj/boot #Mon Nov 02 09:37:08 CET 2015 BOOT_CLOJURE_VERSION=1.7.0 BOOT_VERSION=2.4.2 #App version: 2.2.0

martinklepsch08:11:22

either you have another boot on your path or you downloaded the wrong file

catonano08:11:28

where should I look for a boot.properties file ?

martinklepsch08:11:49

in your current directory and ~/.boot/

martinklepsch08:11:08

which -a boot should list all boot executables on your PATH

catonano08:11:04

I see no boot.properties file

catonano08:11:16

which -a boot returns ""/usr/local/bin/boot"

catonano08:11:28

java -version openjdk version "1.8.0_65" OpenJDK Runtime Environment (build 1.8.0_65-b17) OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)

catonano08:11:38

ok, a minute

catonano08:11:48

"Please download latest Boot binary: https://github.com/boot-clj/boot#install"

martinklepsch08:11:07

can you paste the md5 of the file you just downloaded?

martinklepsch08:11:30

This is pretty strange so far simple_smile

catonano08:11:48

yes, just a minut

catonano08:11:39

here: md5sum /usr/local/bin/boot 07d299924303d67196345621428fde66 /usr/local/bin/boot

martinklepsch08:11:39

Hm. Same that I have. echo $BOOT_VERSION showed nothing right?

catonano08:11:37

right: nothing

catonano08:11:05

an empty line

martinklepsch08:11:40

can you try setting it to 2.4.2 and running boot -V again?

catonano08:11:51

here $ boot -V Downloading https://github.com/boot-clj/boot/releases/download/2.4.2/boot.jar...done. #https://github.com/boot-clj/boot #Mon Nov 02 09:56:37 CET 2015 BOOT_CLOJURE_NAME=org.clojure/clojure BOOT_VERSION=2.4.2 BOOT_CLOJURE_VERSION=1.6.0 #App version: 2.4.2

catonano08:11:18

and $ echo $BOOT_VERSION 2.4.2

martinklepsch08:11:59

~/.boot/cache/boot.properties

martinklepsch08:11:10

do you have this one?

catonano08:11:11

$ cat .boot/cache/boot.properties #https://github.com/boot-clj/boot #Mon Nov 02 09:22:13 CET 2015 BOOT_CLOJURE_VERSION=1.7.0 BOOT_VERSION=2.4.2

catonano08:11:55

I also have a .profile.boot (I didn't remember about it, sorry) $ cat .profile.boot (require 'boot.repl) (swap! boot.repl/default-dependencies concat '[[cider/cider-nrepl "0.8.2"]]) (swap! boot.repl/default-middleware conj 'cider.nrepl/cider-middleware)

martinklepsch09:11:12

profile.boot shouldn’t make any difference

martinklepsch09:11:59

I can only assume that the boot.properties file contained something other than 2.4.2 before you set the env var and ran boot. Maybe check when it has been last modified?

catonano09:11:04

$ ls -la .boot/cache/boot.properties -rw-rw-r--. 1 me me 110 2 nov 09.22 .boot/cache/boot.properties

martinklepsch09:11:21

Hrm. Don’t have a good explanation now. I think I’d recommend to delete .boot/cache/boot.properties and pin boot on a per project basis if wanted.

catonano09:11:22

Not that I need it, just out of curiosity: how do I make it use clojure 1.7 ?

catonano09:11:48

ah BOOT_CLOJURE_VERSION

catonano09:11:20

Thank you, Martin

ska09:11:23

Hi. I've probably missed it. What is the supposed way to start a new boot-compiled project. The equivalent to lein new...

martinklepsch09:11:41

@ska: there is no such thing yet

martinklepsch09:11:08

(where yet means “until someone makes one”)

ska09:11:09

Ok, thanks. So for the time being the equivalent is lein new ABC && rm -f project.clj 😉

martinklepsch09:11:20

something like that yeah

martinklepsch09:11:21

creating some scaffolding stuff in boot could be fun using the fileset but it’s not a popular thing to do in Clojure and so there has not been much effort in that direction

pesterhazy11:11:35

plus there's no reason not to use lein new even for boot projects

pesterhazy11:11:05

it's just another piece of lein functionality, unrelated to dep management

pesterhazy11:11:27

why rewrite something that works? simple_smile

martinklepsch11:11:44

I agree that there’s no reason not to use it but there’s also much to be desired when authoring templates for lein new

pesterhazy11:11:01

I didn't realize

pesterhazy11:11:09

but we could fix lein new, too

martinklepsch11:11:56

e.g. a simple framework for sexp transforms is something I’d expect from a lisp-language project generation tool

martinklepsch11:11:22

another thing could be to have multiple independent steps like 1) inject boot-cljs compilation 2) inject om.next 3) inject datascript — those steps not knowing about each other would be impossible with lein new afaik

pesterhazy11:11:12

might make project generation a bit more complicated than simple template substitution

martinklepsch11:11:46

s/complicated/powerful & reusable/ 😛

micha13:11:07

@catonano: is everything working for you now?

martinklepsch13:11:03

@micha: is boot ever writing to ~/.boot/cache/boot.properties?

micha13:11:19

not anymore, no

micha13:11:25

it's supported for compatibility

micha13:11:41

but it's the least priority way to set things

micha13:11:58

it's been replaced by BOOT_HOME/boot.properties

martinklepsch13:11:05

that makes sense

micha13:11:17

because it now supports other settings beyond what boot writes there

martinklepsch13:11:27

yeah I was just surprised that it has been touched

$ ls -la .boot/cache/boot.properties 
-rw-rw-r--. 1 me me 110  2 nov 09.22 .boot/cache/boot.properties

micha13:11:23

yeah that will be overridden by BOOT_HOME/boot.properties, <git project>/boot.properties, ./boot.properties, environment variables, and system properties

micha13:11:25

in that order

martinklepsch13:11:24

right. I assume that @catonano didnt change that file himself though(?)

micha13:11:44

no probably not

martinklepsch13:11:50

does boot ever write to any boot.properties files without using sth like > boot.properties?

micha13:11:19

it uses the .load() method of the Properties instance

micha13:11:53

with a FileOutputStream for files

micha13:11:05

or stdout, as the case may be

micha13:11:21

in any case the load method writes to an output stream

micha13:11:42

oh i mean the .store() method

micha13:11:49

not .load()

martinklepsch13:11:24

why does it write though? is that necessary? it seems like this does some system wide pinning without the user asking for it?

micha13:11:24

maybe it's no longer necessary

micha13:11:31

i'm not 100% sure of all the implications

martinklepsch13:11:49

big :+1: for all the stuff you did yesterday btw simple_smile lots of good stuff coming up in the next release simple_smile

catonano17:11:03

@micha thank you so much for your concern. Yes, everything is fine, now

micha17:11:34

deleting ~/.boot/cache is what fixed it?

catonano17:11:04

@martinklepsch: no I didn't change that file myself

catonano17:11:46

@micha: I guess so. I also deleted ./boot/boot.properties (it indicated clojure 1.6)

catonano17:11:10

I mean .boot/boot.properties

catonano17:11:22

cleaning the .boot folder set things straight

martinklepsch17:11:42

@catonano: your file was at ~/.boot/cache/boot.properties iirc

catonano17:11:57

yes, there was ALSO .boot/boot.properties

catonano17:11:28

I' m sorry I can't be more precide in my reporting

jstokes19:11:26

can anyone tell me how to start the repl server such that i can connect from a remote host with boot? i’ve tried (repl :server true :port 1337 :host "0.0.0.0”) but it still comes up bound to 127.0.0.1

micha19:11:35

@jstokes: i think you want the --bind option there, instead of --host

micha19:11:45

-b, --bind ADDR       Set the address server listens on to ADDR.
 -H, --host HOST       Set the host client connects to to HOST.

jstokes19:11:35

thanks @micha

micha21:11:36

why can't weasel etc run in a pod?

juhoteperi21:11:04

@micha: Because they are nrepl middlewares

micha21:11:36

but the repl server doesn't need to be in the same context as the boot.user namespace for the project, does it?

micha21:11:52

like the compiler pod could spin up a repl server in the pod

juhoteperi21:11:53

I don't know

juhoteperi21:11:04

If it's possible, it would require some changes to repl task?

micha21:11:23

i think you'd just start the repl in the cljs-impl code

micha21:11:26

without a task

micha21:11:39

like what figwheel does i think

micha21:11:58

i think it makes sense for the cljs compiler to provide the repl server

juhoteperi21:11:15

Hmm separate nrepl? Yes could be

juhoteperi21:11:29

Editors afaik anyway open separate nrepl connection for cljs context

micha21:11:58

i think that move would eliminate most of the dependency hell problems

juhoteperi21:11:43

As quick fix I think I'll implement the changes mentioned in GH issues for next release, but I'll keep this in mind

juhoteperi21:11:15

also if/when we move to Figwheel client code, we could make use of it's REPL client and perhaps repl server

micha21:11:18

boot master has show -p and show -d for all pods btw

micha21:11:44

in case that helps with tracking down deps issues in pods

juhoteperi21:11:30

For Figwheel client code I would be interested to figuring out how to include Figwheel code for Cljs compilation without transitive dependency

juhoteperi21:11:39

Perhaps by adding the client code to fileset from boot-reload task?

micha21:11:31

why not put it in a pod?

juhoteperi21:11:11

I'm not sure but I presume it needs to be part of the same Cljs compilation as other code

micha21:11:43

yeah it could go in the cljs compiler pod

micha21:11:49

as part of boot-cljs

juhoteperi21:11:15

Hmm, yeah, boot-cljs could read additional dependencies for the pod from cljs.edn or somewhere

micha21:11:47

i mean why not just add it to the cljs compiler pod always?

micha21:11:55

and just turn it on and off by options

micha21:11:24

i'm sure the figwheel options map can be simplified by using cljs.edn for many things

juhoteperi21:11:26

It depends on how closely we want to tie boot-cljs/boot-reload/boot-cljs-repl together

micha21:11:53

seems like things that need to talk to the compiler directly and not just consume data

micha21:11:01

those things need to be part of the compiler task

juhoteperi21:11:10

Yeah, cljs-repl will need to do that

micha21:11:11

or be refactored to consume data

juhoteperi21:11:15

But not sure about boot-reload

micha21:11:13

yeah the repl seems impossible to do otherwise really

juhoteperi21:11:22

Tough I guess cljs-repl could be separate task if cljs task would publish required options, mostly output-path

micha21:11:23

until socket repls are a real thing perhaps

micha21:11:46

fileset metadata perhaps

juhoteperi21:11:19

Perhaps. But would also be quite messy for cljs-repl to touch files in output-path (boot-cljs temp dir)

micha21:11:35

and it needs that info because it's running its own compiler

micha21:11:42

which seems like a messy way to do things

micha21:11:56

otherwise it could just use the boot-cljs compiler instance

micha21:11:02

that is already configured etc

micha21:11:22

repl and compiler seem like two sides of the same coin anyway

micha21:11:36

seems ok to combine them

micha21:11:47

you can always make a separate cljs-repl task anywy

micha21:11:56

and that wouldn't be interfered with

juhoteperi21:11:20

Will be interesting to see in some months how Socket repl turns out

micha21:11:55

that will basically allow you to run the nrepl part in a separate pod from the repl server, right?

micha21:11:05

they can talk to each other over the socket connection?

martinklepsch21:11:55

+1 for repl + compiler using same compiler pod

martinklepsch21:11:10

@juhoteperi: what’s the interesting bit about socket repl for you? I recently tried to see where it fits in but it seems that all problems it’s solving have already been solved?

juhoteperi21:11:21

@martinklepsch: Nothing specific. I also think nrepl already solves most or all problems, so it'll be interesting to see if someone can think up something where socket repl is really useful.

pandeiro22:11:34

do pods inherit the dependencies declared in the boot.user env ?

juhoteperi22:11:01

@pandeiro: Not necessarily, it depends if their env is build from boot.user env

pandeiro22:11:45

the cljs compiler does, right? it has to, no?

pandeiro22:11:03

i'm :+1: on rolling boot-cljs-repl into boot-cljs, as long as it continues to support adding additional nrepl options and reading nrepl middleware out of profile.boot

pandeiro22:11:44

sounds like it could facilitate a proper fix for #32 as well

pandeiro22:11:17

my solution to #32 is just exposing an :output-dir option to cljs-repl so I can at least re-name out to something else

juhoteperi22:11:19

Yeah it'll be much easier to set proper options for repl when it can access cljs compiler dirs etc.

pandeiro22:11:35

but yeah ^^^ that seems like the right thing

martinklepsch22:11:33

@juhoteperi: @pandeiro couldn’t we infer output-dir from cljs.edn location?

martinklepsch22:11:00

@micha: since we have 2.5.0 in version.properties, should we have a new release?

pandeiro22:11:37

@martinklepsch: it would seem so, i guess. but i think weasel needs :output-dir set explicity - how would you refer to that/those location(s)?

martinklepsch22:11:39

I think it might be worth adopting some 1.0.0 > 1.1.0-SNAPSHOT > 1.1.0 kind of cycle for commits between releases

martinklepsch22:11:09

@pandeiro: afaik boot-cljs doesn’t support custom output-dirs so they are just (f build-id)

martinklepsch22:11:08

(that said I don’t even know if we would want to set them to the same directory as the compiler output dir?)

pandeiro22:11:23

i assume so... right?

martinklepsch22:11:05

I’m not sure. This could mean that if you eval something in the repl and reload the repl state is being loaded

martinklepsch22:11:31

because it overwrites existing js/cljs files in output-dir

pandeiro22:11:48

yeah tough call there

martinklepsch22:11:47

I guess we could just make it target/main.out-repl instead of target/main.out or something like that

pandeiro22:11:02

yeah that would make sense i think

pandeiro22:11:46

ok i've tried to add in :output-dir and pass that along to weasel.repl.websocket/repl-env but it doesn't seem to make a difference

martinklepsch23:11:49

@pandeiro: have you checked that the value is actually being passed to the weasel repl-env invocation?

martinklepsch23:11:28

If it really has no effect — bug in weasel?