Fork me on GitHub
#boot
<
2016-01-12
>
richiardiandrea00:01:34

another question, is there a zeal/dash docset for boot?

jethroksy02:01:13

@micha: any intention to make it pull latest?

alandipert02:01:01

@richiardiandrea: not that i know of but that would be awesome

jethroksy02:01:03

nvm i realised it pulls latest anyway

richiardiandrea02:01:01

@alandipert: definitely! We'll schedule it for the next free time slot

richiardiandrea02:01:20

A question, when I call pod/with-call-worker in a boot repl session, which classpath can I see in the call?

richiardiandrea02:01:42

for example I see boot.core...but do I see a custom namespace?

alandipert02:01:21

boot starts up a singleton pod for its own purposes called the "worker pod"

alandipert02:01:29

it's where dependencies for various tasks live

alandipert02:01:37

task implementations, rather - like jgit

alandipert02:01:09

with-call-workr runs things in there, probably not what you want to use in yuor own project. the classpath you see is the worker's

richiardiandrea02:01:21

oh ok, that is why all the calls were wrapped, I am importing jgit and using it, I guess I do not need a custom pod for this right?

alandipert02:01:51

not necessarily, but i would say if you needed things in addition to jgit, probably best to make your own pod

alandipert02:01:58

so as to not cause problems with the rest of boot

richiardiandrea02:01:35

my project is basically about a custom task that will use jgit, I don't think I am going to use more than this

richiardiandrea02:01:58

how and when there can be a conflict? in case the caller of my task is itself using jgit right?

alandipert02:01:29

to mess things up you'd need to add more dependencies to the worker pod

alandipert02:01:36

which is not an especially easy thing to do so i wouldn't worry about it

alandipert02:01:23

boot.pod/add-classpath would be the way to do it

richiardiandrea02:01:07

ok, I am just trying to baby understand whether I need to create my own pod when my task uses external jars like jgit

richiardiandrea02:01:28

the caller of my task will have jgit on the classpath right, another way to say this is, is each task you require executed in its isolated pod automatically?

alandipert02:01:42

i see what you're getting at

alandipert02:01:59

are you learning clj along with boot or have you been at it for awhile?

richiardiandrea02:01:11

at it for a while

alandipert02:01:38

so yeah the way we tend to do it is to make a pod in a closure that closes over the function users call

alandipert02:01:59

like (let [x (atom 0)] (defn inc! [] (swap! x inc)))

alandipert02:01:20

except make-pod instead of atom

richiardiandrea02:01:30

ok, so one unique pod for all the call chain

alandipert02:01:42

yeah. for efficiency we have a pod-pool thing

alandipert02:01:51

that's conceptually similar except maintains a pool of warm pods

richiardiandrea02:01:58

right, I read about it in the wiki

richiardiandrea02:01:59

so practically each "custom" task that has transitive dependencies, adds them to whatever classpath/pod the caller has

alandipert03:01:53

(deftask inctask []
  (let [p (future (boot.pod/with-eval-in (boot.pod/make-pod (boot.core/get-env)) (def n (atom 0))))
            pod-inc! (boot.pod/with-eval-in @p (swap! n inc))]
    (fn [next-handler]
      (fn [fileset]
        (println "The number in the pod is now: " (boot.pod/with-eval-in @p @n))
        (next-handler fileset)))

alandipert03:01:32

def n var in the pod isn't visible in the rest of the program

richiardiandrea03:01:04

wow cool stuff 😄

alandipert03:01:15

on the 2nd line of that example when the pod is made, it starts with whatever the user's environment is set up to be

alandipert03:01:30

then usually we add our own task-specific dependencies to that

richiardiandrea03:01:22

ok great so in theory if I want to be clean I should create a new pod where I add jgit and use it in the pod only

alandipert03:01:03

you can then either run code in the pod directly with with-eval-in, or you can require namespaces in the pod. the latter is good if you have a lot of code to run in the pod

richiardiandrea03:01:03

or my caller, if she is going to include jgit as well, will have a clash

alandipert03:01:03

yeah. you may choose to start your pod with (dissoc (get-env) :dependencies)

alandipert03:01:54

then you pick up the environment minus any dependencies, which could include jgit. another option is detecting if jgit is already loaded and not loading it into your pod if so

richiardiandrea03:01:29

yes but I would depend of whatever version my caller/boot has

richiardiandrea03:01:38

emptying the env is scary because I then need to include back all the deps that jgit needs

richiardiandrea03:01:53

but I guess I need to do it anyways

alandipert04:01:15

yeah it's easy - (-> (get-env) (assoc :dependencies '[[jgit ...]]))

meow04:01:33

heya booties!

jethroksy04:01:05

@micha: no more docker woes after swapping to arch on my office machine! ^^

flyboarder05:01:40

@jethroksy: how do you like arch? a friend of mine keeps suggesting i switch

jethroksy05:01:22

I love it, quick to install and has a great package manager

jethroksy05:01:05

i do a custom bspwm setup on my home desktop, but if you're too lazy you could always install any DE

flyboarder05:01:19

ill have to give it a go sometime

tolitius06:01:29

@seancorfield: hey, just wanted to see how the https://github.com/seancorfield/boot-new idea is going ( selfish reasons simple_smile )

seancorfield07:01:50

I hope to put up a first cut this week. I had hoped to do it last week but life got in the way.

magomimmo08:01:38

@martinklepsch: > wouldn't it make sense to use boot for local installation as well if you're already using it for everything else?

magomimmo08:01:19

@martinklepsch: I finally did it. Hopefully for the better...

meow08:01:22

@magomimmo: very cool that you are updating all your tutorials

magomimmo09:01:24

@meow: yep. I’m thinking about the next steps….probably test.check, then the reactive stuff...

oskarth10:01:34

How do I do the equivalent of :repl-options {:init (set! *print-length* 50)} (in leiningen) in boot? (task-options! repl {:init-ns 'notification-sender. core :eval (set! *print-length* 50)}) fails due to "Can't change/establish root binding of: print-length with set".

oskarth10:01:49

:eval isn't quite right either as I want it to happen in my init-ns and not in the boot namespace, but it was the closest I could find in https://github.com/technomancy/leiningen/blob/master/sample.project.clj for in-line evaluation

oskarth11:01:58

I also found this http://blog.michielborkent.nl/blog/2015/06/06/from-leiningen-to-boot/ which suggest :eval '(set! *print-length* 50) in task-options for repl, which makes sense, but that still doesn't change the print-length var once booted.

jaen11:01:50

Hmm, I'm not sure how to properly set it in boot, but I remember setting this can cause some startling errors in things that rely on pr-str and then being able to read-string it.

jaen11:01:23

I think sending objects to boot pods was one thing like that, so I'm unsure if setting this is a good idea.

martinklepsch11:01:58

@jaen: seems strange to me that print-length would affect pr-str, almost like a bug if so?

martinklepsch11:01:35

@oskarth: you mean you have the set! call in :eval and it's still printing more than 50lines?

oskarth11:01:11

@martinklepsch: yes, *print-length*` => nil

jaen11:01:24

@martinklepsch: I might be misremembering exact functions, but I'm pretty sure someone had an issue with that. If free slack had full search...

martinklepsch11:01:52

How are you connecting to the repl server?

oskarth11:01:04

printing too large collections causes spacemacs to crash multiple times a day, so pretty useful feature 😛

martinklepsch11:01:15

Try in a directory without build.boot and all specified via cli maybe

oskarth11:01:20

martinklepsch: jack-in, cider repl -s waitafaik

martinklepsch11:01:49

And you have a top level task options call?

oskarth11:01:52

why would that make a difference? the problem is just how to instrument boot to do init repl-options, no?

oskarth11:01:00

yes. init-ns works

martinklepsch11:01:27

Just trying to reduce surface area :)

jaen11:01:35

@martinklepsch: seems I wasn't misremembering.

boot.user=> (pr-str [1 2 3 4])
"[1 2 3 4]"
boot.user=> (set! *print-length* 2)
2
boot.user=> *print-length*
2
boot.user=> (pr-str [1 2 3 4])
"[1 2 ...]"

oskarth11:01:47

does anyone have a similar setting?

jaen11:01:41

Not the safest thing to set IMO if that's the result.

martinklepsch11:01:49

Are there other fns that do the same thing as pr-str but without pr?

oskarth11:01:03

that makes sense though, it's printing

martinklepsch11:01:09

@oskarth: I can give it a try here in a bit

jaen11:01:53

Yeah, but the problem is some use it to serialise things and it will break then.

oskarth11:01:07

shouldn't those things check print-length?

oskarth11:01:15

or what do you mean?

jaen11:01:26

Not that it is a right way to serialise things, but I remember someone raising an issue here on slack that something broke

jaen11:01:39

And CIDER setting *print-length* was the culprit.

martinklepsch11:01:47

I guess those things shouldn't use pr-star in the first place the.

oskarth11:01:47

it seems fragile to rely on print behaviour like that, but maybe that's just me

jaen11:01:02

Yes, I agree it is.

jaen11:01:23

Just something for you to be aware of. It might help you when you get an inscrutable error like that guy back then.

jaen11:01:26

As for serialising Clojure without pr - I suppose you're only left with external libs like EDN or something. But I don't know the whole stdlib by heart.

oskarth11:01:52

I'll look at this later today, need to get some real work done now 😛

oskarth11:01:13

thanks for some pointers though, ttyl

juhoteperi11:01:06

Hmmh. If I have direct ClojureScript dependency with test scope, uber task will still include clojurescript dependency, probably because some other dependency has transitive dependency to clojurescript.

jaen11:01:38

Found it, starts at the bottom of the first link, the *print-length* being the reason is at the start of the second. http://clojurians-log.mantike.pro/clojurescript/2015-11-19.html http://clojurians-log.mantike.pro/clojurescript/2015-11-20.html

jaen11:01:36

@oskarth: also this last link (the issue) seems like something that can be an answer to your question.

meow13:01:41

you all rock ♥️

micha14:01:34

@juhoteperi: that's an interesting thing, do you think uber should add :exclusions?

micha14:01:39

i think maybe it should

micha14:01:12

or maybe the uber scopes thing is nonsense

juhoteperi14:01:15

@micha: Not sure, it is sometimes possible that some dependencies really require something that is in test scope in project

micha14:01:20

and we should get rid of that

micha14:01:48

yeah i think in the uber case you're not making a library that has dependencies of its own anyway

juhoteperi14:01:50

At least I wouldn't probably add any more logic

micha14:01:02

you're making an application

micha14:01:21

so scopes probably don't really make sense in the context of the project

juhoteperi14:01:34

In case one wants to optimize uberjar size, I think it's best to sift the fileset

juhoteperi14:01:13

We are already using test scope for things which it is not supposed to be used

juhoteperi14:01:53

Maybe. But I guess it doesn't matter that we are using it for build deps.

micha14:01:25

how are we abusing test scope?

micha14:01:22

also i think a better way than :scope "test" might be to use the :dependencies option in the pom task

micha14:01:29

and keep the two separate

juhoteperi14:01:45

"This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases."

micha14:01:45

that option lets you just directly specify which deps are in the pom

juhoteperi14:01:13

We are not strictly using it for test compilation and execution

micha14:01:39

and we don't use it for "applications"

micha14:01:49

nor do any of the libraries in maven central

micha14:01:02

so i think the docs are maybe slightly misleading there

micha14:01:05

but yeah i agree that it's not a good fit

micha14:01:42

i used to think it was a good way but especially with like boot-cljs you can see the limitations

micha14:01:08

so now i think it's probably better to decomplect things

micha14:01:22

and not try to declaratively express it in scope annotations

magomimmo15:01:24

@micha: and @juhoteperi in the latest tutorial of modern-cljs I briefly wrote about dependency scope. Hopefully I did not write something wrong (it’s a complicated topic). It would be a pleasure to have your comments, specially if I wrote something less than accurate. https://github.com/magomimmo/modern-cljs/blob/master/doc/second-edition/tutorial-20.md#dependency-scope

mccraigmccraig15:01:32

is there a boot equivalent to lein's :pedantic? :abort ?

meow15:01:31

@magomimmo: keep up the good work

meow15:01:58

@micha: been a minute - hope you are well 🍻

micha15:01:25

@meow: can't complain, how have you been?

magomimmo15:01:09

@meow: I decided the title of the next tutorial - Think more to code less simple_smile

meow15:01:50

@magomimmo: I do like the sound of that

meow15:01:28

@micha: I have been great. Busy. Moving on Thursday. Helping with #C0CB40N8K and #C0J20813K

magomimmo15:01:17

@meow: yep, is the sound of the abstraction...

micha15:01:45

@meow: that's pretty sweet, i was watching the braid videos this morning

micha15:01:09

looks great so far

meow15:01:17

wanna invite?

meow15:01:26

dogfood is yummy

micha15:01:37

sure! thanks!

meow15:01:27

@rafd: another invite please? for @micha ^

meow15:01:00

after you join do a search for the word "fuck"

meow15:01:11

that's the best way to see old content

meow15:01:27

prepare to be horrified

jaredly15:01:58

@meow: I do think I remember a CoC taking about profanity...

jaen15:01:55

Indeed it does : V

meow15:01:01

we all make mistakes

meow15:01:58

can we make an exception because the on-boarding process for #C0J20813K is to enter "fuck" into the search box

meow15:01:31

its the best introduction to the system - trust me

meow15:01:50

@jaen: wanna invite?

meow15:01:21

I know you will say yes, so @rafd can we get another

jaen15:01:22

Have one since some. But isn't that a boot channel though? : V

jaredly15:01:40

braid is super cool

jaen16:01:54

I don't care much about this, since if I was so easily annoyed by such things then I would probably already be cursing at the attitude the Clojurescript maintainer has, but I've seen people get agitated here when someone used at-everyone or babbled incessantly in general (a non-partable channel). So you might want to take care to not annoy people like that, which self-inserts into so many channels can do. Friendly advice, nothing more.

oskarth16:01:24

@jaen @martinklepsch so boot repl in terminal sets print-length, whereas jack-in (using the profile.boot from step 2 inhttps://github.com/boot-clj/boot/wiki/Cider-REPL) switches the init-ns but doesn't set print-length

oskarth16:01:41

this is using a build.boot with (task-options! repl {:init-ns 'notification-sender.core :eval '(set! *print-length* 20)}) at the top-level

martinklepsch16:01:58

maybe this is more cider than boot related?

oskarth16:01:34

I'd say it's right in between the two, since the equivalent flow for leiningen works

oskarth16:01:28

it's not clear to me whether this is a configuration issue with cider or boot, though

oskarth17:01:07

how does boot deal with nrepl?

martinklepsch17:01:13

if you run the repl task without --server and check *print-length* right there?

oskarth17:01:32

if I just want to start a nrepl server with boot and connect via emacs, how do I do that?

oskarth17:01:39

there's no --server - what do you mean?

martinklepsch17:01:03

ah, then just check in the repl that comes up

martinklepsch17:01:15

thought you were using -s but maybe that was from a prev. message

oskarth17:01:23

that's what jack-in runs afaik

oskarth17:01:48

running just boot repl works now using profile.boot and setting BOOT_HOME (don't think this worked before)

oskarth17:01:23

cider-jack-in starts a nrepl server for current project, so that seems like a natural thing to try to do manually. How do I do that with boot?

oskarth17:01:59

that starts the client too

martinklepsch17:01:08

boot repl --server/-s starts a server without a client but they're essentially the same

oskarth17:01:24

"essentially" 😉

oskarth17:01:32

ok lets try that

oskarth17:01:09

hm, for whatever reason I can't connect

oskarth17:01:23

could be something to do with my spacemacs config though

oskarth17:01:04

cider-connect => localhost => [weird empty screen] 55564 [port of nreplserver] => connection failed

martinklepsch17:01:34

Look, just cut cider out of the equation and see if that works

martinklepsch17:01:54

boot repl — and then see if *print-length* is correctly set

oskarth17:01:54

I told you it did?

oskarth17:01:07

it does set it

oskarth17:01:28

still not clear cider per se is the problem, could be something with the order of sending messages when it starts the nrepl server, or that cider is too tightly coupled with lein. I don't know which it is

martinklepsch17:01:50

I don't see where? sorry if so. You can also try doing boot repl -s and boot repl -c in different terminals but I believe boot repl is equivalent

oskarth17:01:29

"so boot repl in terminal sets print-length" and "running just boot repl works now using profile.boot and setting BOOT_HOME (don't think this worked before)" - sorry if that wasn't clear

oskarth17:01:15

ConnectException Connection refused upon boot repl -c -H 127.0.0.1 -p 55648 when boot repl -s is running at nREPL server started on port 55648 on host 127.0.0.1 - (docs: https://github.com/boot-clj/boot/blob/7605a731902a77b577ad1aa869166612568d866d/boot/core/src/boot/task/built_in.clj#L289-L292)

oskarth17:01:37

perhaps I'm invoking the param opts wrong

oskarth17:01:17

I wonder if there's something going on with boot and nrepl - does boot actually separate the server and client like nrepl specifies or does it do something else?

oskarth17:01:35

Alternatively, could it be that certain packages are required to be in build.boot (outside of those defined in profile.boot) for cider/nrepl to work? I just have my project's packages in there.

oskarth17:01:18

Other thing: .nrepl-port doesn't seem to be set upon boot repl -s. Could open an issue for this.

oskarth17:01:44

and if I edit .nrepl-port manually and run boot repl -c only I get "URISyntaxException Illegal character in authority at index 8: <nrepl://127.0.0.1:55875>" which is quite interesting

martinklepsch17:01:43

shot in the dark: is boot up-to-date?

oskarth17:01:50

Left work, will check when home

onetom18:01:56

whats up w this braid chat? is the clojure community is trying to switch over to it from slack? i would be happy to try it too. already running gitter, slack, whatsapp, line, wechat, hipchat...

jaen18:01:25

@oskarth: checked out my last link? That issue seemed to have a similar use case to yours and mentioned using the boot-shim.clj file.

seancorfield18:01:49

@onetom: Checkout #C0CB40N8K if you’re interested in the whole Slack / Braid / whatever discussions.

oskarth18:01:11

@jaen I did, but the last comment is what I have already, no? Will try boot shim too

jaen18:01:10

Ah right, I thought something is still not working properly and that maybe the shim will work. Sorry if that's not the case.

oskarth18:01:09

It might, I'll try it soon

oskarth18:01:43

There seems to be a lot of issues related to nrepl, or maybe my configure is just borked

oskarth18:01:27

@martinklepsch: boot version 2.5.5, so seems to be up-to-date (not clear from GH page what the stable etc version is.)

oskarth19:01:26

Tried the boot-shim thing using absolute path and :init key

micha19:01:26

boot -u will get you the latest stable release

oskarth19:01:42

I have the latest release.

micha19:01:13

i don't fully understand all the ins and outs of the nrepl architecture

micha19:01:27

so the boot repl support is not ideal

oskarth19:01:31

To be honest, there seems to be too much broken around nrepl stuff (see nrepl server/conn / no .nrepl-port set) and lack of documentation (repl options, nrepl stuff) for this to be worthwhile. Already spent too many hours on this small thing. I'm gonna stop now and just hack it for onw.

micha19:01:05

the .nrepl-port is a new issue that hasn't been reported before

oskarth19:01:15

I can open an issue if you want

oskarth19:01:40

If the nrepl stuff worked for certain then it'd be easier to see where exactly the problem is, cider or boot or in between

micha19:01:55

boot repl should always work

micha19:01:19

if it doesn't then it's very likely that something in your environment is interfering

micha19:01:34

we haven't had any issues there at all

oskarth19:01:55

what I mean with nrepl was to separate boot repl into two steps: boot repl -s and boot repl -c

oskarth19:01:09

to see if nrepl connection was working at all, which is a prereq for cider

micha19:01:21

yes, that part is very stable in boot

oskarth19:01:25

I really don't feel like spending more time on this right now though, I'm sorry.

oskarth19:01:34

it didn't work for me on 2.5.5

micha19:01:38

no worries!

oskarth19:01:45

see issues above

oskarth19:01:02

anyway I'm out, ttyl!

micha19:01:12

later! let me know if i can help in any way

pandeiro19:01:43

I'm trying to upgrade to 2.5.2/2.5.5 and my process gets stuck on Retrieving pod-2.5.5.jar from

micha19:01:35

could be network issues

pandeiro19:01:21

yeah i guess so, seems like it's just clojure dependencies that are affected though 😄

pandeiro19:01:31

both maven central and clojars

pandeiro19:01:46

am I getting rate limited?

tcrawley19:01:00

clojars has no rate limiting

pandeiro19:01:32

@tcrawley: thanks I was saying that in jest, sorry

tcrawley19:01:32

looking at the acccess log, I don't see anything weird around pod-2.5.5 requests

pandeiro19:01:07

It does seem to only be happening with dependencies the new version of boot is trying to fetch though

micha19:01:17

is your disk full?

pandeiro19:01:20

first it was stuck on shimdandy-impl and now pod

pandeiro19:01:26

oooh good call

micha19:01:32

or nearly full

pandeiro19:01:43

96%, 22G left

oskarth19:01:32

well, it's all above micha but:

oskarth19:01:56

gah x2: 1. boot repl server is started with boot repl -s wait, not boot repl -s - explains missing nrepl-port 2. github opens issues before you hit enter

micha19:01:25

how does that explain missing nrepl port file?

oskarth19:01:36

because without the wait the nrepl-port is deleted

oskarth19:01:51

this should really be clear in docs imo, big diff from lein

micha19:01:05

oh, yeah you need the wait

micha19:01:10

or the process ends

micha19:01:18

boot tasks generally don't block the pipeline

oskarth19:01:25

wish someone said that earlier when I was beating my head against it 😛

micha19:01:28

so you can do boot repl -s watch build-it

oskarth19:01:52

with that out of the way I can try to reproduce the repl-options thing

micha19:01:56

the only built-in tasks that block the pipeline in any way are the wait task and repl --client, and watch

micha19:01:10

boot repl implies both --server and --client

micha19:01:22

it's just comp of the two

micha19:01:13

another thing that might be relevant is that the nrepl server is running in the same pod as your build.boot

micha19:01:21

but the client is running in its own pod

micha19:01:35

so as not to pollute your project with REPLy dependencies

micha19:01:43

REPLy has some hairy ones

micha19:01:17

there is no way around loading nrepl itself into the main pod, because you want the session to be in the main pod context

micha19:01:57

but the repl server will load the nrepl dependency dynamically at runtime if your project doesn't already have an nrepl dependency

micha19:01:23

so if you're not using the repl task there will be no nrepl on the classpath unless you have it as a dependency in your project

micha19:01:37

the repl client library

micha19:01:45

does all the fancy completion etc

oskarth19:01:15

I thought that was cider

pandeiro19:01:18

weird, I can retrieve [boot/pod "2.5.5"] with lein but not with boot

oskarth19:01:48

next step is probably to read elisp code for cider-jack-in, see how it works differently from starting a nrepl server and connecting to it

micha19:01:22

cider might not use a repl client at all

micha19:01:32

i think it might be a repl client itself

micha19:01:41

talking directly to the server

micha19:01:01

in which case REPLy isn't relevant

pandeiro19:01:46

...and I can get boot/pod with boot 2.3.0 installed locally, but not with a boot 2.5.5 docker container

micha19:01:30

@pandeiro: try with boot -v

micha19:01:40

it might just be slow in the container

micha19:01:48

you'll see progress reports with -v on

micha19:01:56

from aether as it downloads

micha19:01:27

the aether stuff is fully instrumented in verbose mode

pandeiro19:01:55

crazy, that time it got pod and got stuck on core, the next dep

micha19:01:10

are you seeing it downloading?

micha19:01:18

where is it stuck at?

pandeiro19:01:23

@micha: not visually, no

micha19:01:36

you should see lots of output from aether

pandeiro19:01:36

just says the "Retrieving..." line

micha19:01:44

i mean the debug output

micha19:01:52

should be a map of data

micha19:01:03

with all the info about which stage of the process it's at

oskarth19:01:09

I'm here right now: https://github.com/clojure-emacs/cider/blob/e284271133d5a7d736e457cd587fa598e9ff404a/cider-repl.el#L198 - a lot of non-boot specific things, but my current hypothesis is that repl-options are evaluated differently in the nrepl server/conn lifecycle in lein and boot. Pretty big deep hole for my knowledge of this stuff though.

micha19:01:00

there is an issue about that, @oskarth, #1462

micha19:01:08

a cider issue

micha19:01:19

perhaps related

pandeiro19:01:51

@micha: Aether is eventually timing out after a long time... I think this has something to do with docker changing ownership in ~/.m2/repository/<pkg> to root, maybe

pandeiro19:01:02

Still don't see the verbose output though, either

pandeiro19:01:15

Maybe that would only show up once the deps were obtained?

micha19:01:30

ah yeah boots own deps are loaded during the initial boostrapping

micha19:01:34

before it reads the options

micha19:01:46

this is a fixable thing though

micha19:01:51

it's on my list

micha19:01:07

bummer though

micha19:01:35

i recommend loading boot when you build the container

micha19:01:45

set BOOT_LOCAL_REPO in your dockerfile

micha19:01:50

to a directory in the project

oskarth19:01:52

micha: that is very much related, thanks

micha19:01:53

and ADD that dir

oskarth19:01:59

"Boot has an option to provide :eval form but only for the client — it doesn't work if REPL is started in server mode."

micha19:01:54

i think maybe i can add the fix for that as 2.6.0 release, and push the stuff in 2.6.0 to 2.7.0

micha19:01:03

to get it out faster

oskarth19:01:14

oh ok, so the issue is between cider and boot

oskarth19:01:22

guess it doesn't matter

micha19:01:34

if you would like to file a boot issue that would be great

micha19:01:58

just to keep track of it

pandeiro20:01:34

Does Boot 2.5.5 still throw a warning if :target-path is specified in merge-env! ?

micha20:01:06

it warns if BOOT_EMIT_TARGET is not set to no

pandeiro20:01:30

is the only way to get rid of that warning adding (target ...) to all of my tasks?

pandeiro20:01:44

can I use task-options!?

micha20:01:56

no, you can just add BOOT_EMIT_TARGET=no to your boot.properties, or your shell environment variuables

micha20:01:08

the target task doesn't affect that warning

pandeiro20:01:18

but then boot won't create target?

micha20:01:27

not unless you use the target task

micha20:01:44

you can also supporess deprecation warnings with BOOT_WARN_DEPRECATED=no

pandeiro20:01:56

ok so the target task has become mandatory then basically?

micha20:01:07

only if you want to emit files to a directory

micha20:01:16

usually that's not the case

micha20:01:21

like i never do that

pandeiro20:01:26

building a frontend?

micha20:01:40

either i'm working in development mode which is all on the classpath, or i'm pushing artifacts to the cloud

micha20:01:09

yeah when i build a frontend when i]m working on it i don't need a target dir because i have a local jetty server serving from the classpath

micha20:01:25

and when i deploy the frontend i'm deploying files to s3 or jars to beanstalk or whatever

micha20:01:30

still no target dir involved

micha20:01:35

the implicit target dir brings in some counter-intuitive behavior, like what should boot repl do? should it delete the stuff in the target dir?

micha20:01:55

what if you have two boot processes, do they both clobber each other's target dir?

micha20:01:05

also you pay the cost of writing all those files all the time

pandeiro20:01:10

yeah that was always one of boot's little things simple_smile

micha20:01:24

yeah the whole target-paths thing was a mistake from the beginning

micha20:01:35

the task is much more sane

micha20:01:41

because you know what you want it to do

pandeiro20:01:43

but we have a project with about a dozen tasks, now nearly all of them need (target ...)

pandeiro20:01:47

not a huge deal

micha20:01:02

you can continue using the tartget-path

micha20:01:09

it should still work

micha20:01:25

there are some issues on windows8 with it

pandeiro20:01:29

yeah but if it's warning, that's b/c it's deprecated right?

micha20:01:44

but boot 3.0.0 won't be for a while

pandeiro20:01:55

i wish i could somehow set that in one place

micha20:01:57

not for at least a year

pandeiro20:01:00

as we were doing

micha20:01:09

set what in one place?

pandeiro20:01:20

:target-path

micha20:01:23

ah you can

pandeiro20:01:25

and be done with it

micha20:01:41

(task-options! target {:dirs #{"target"}})

pandeiro20:01:55

but I still need the target invocations

micha20:01:13

i mean you can use the deprecated behavior for a long time still

micha20:01:22

it won't be removed till next year probably

pandeiro20:01:24

sure, no i think we will get on board simple_smile

micha20:01:26

at the earliest

pandeiro20:01:36

it's actually only 3-4 tasks that really need/use that

micha20:01:27

i think you'll see some performance improvements with the other tasks if you use the target task

micha20:01:34

it will do less IO

micha20:01:43

depending on how many and how large the files are

micha20:01:14

i guess most of the time it's not noticeable

micha20:01:33

cause the syncing procedure was already pretty efficient

pandeiro20:01:56

cool, that's always nice

pandeiro20:01:12

one thing I'm seeing now with 2.5.5 is this warning: cli: option output-dir: expected optarg, got str

pandeiro20:01:41

any idea where that comes from? wondering if it's some thing between boot and boot-cljs?

pandeiro20:01:56

i grepped and output-dir is nowhere in the project

micha20:01:00

that's a task that has an error in the task options

micha20:01:04

that means you have like

micha20:01:29

(deftask foo
  [o output-dir str "The output dir."]
  ...

micha20:01:40

that will work in the repl, but not from the command line

micha20:01:55

because it's missing the optarg, like this:

micha20:01:15

(deftask foo
  [o output-dir DIR str "The output dir."]
  ...

pandeiro20:01:26

any way to find the offending task?

pandeiro20:01:33

i think it must be in a dep somewhere (?)

micha20:01:03

you can do boot -h

micha20:01:09

that will show all the tasks that are loaded

micha20:01:13

it will be one of those

micha20:01:35

it's not going to be the built-in ones, so you can eliminate all of those