Fork me on GitHub
#boot
<
2017-02-09
>
mobileink00:02:50

my tasks can then elaborate it by add/change/delete, or use its contents to generate stuff. but they can assume it exists, and only one of it exists.

mobileink00:02:51

iow, a pipeline should always have a msster edn (config) file, all the way thru.

mobileink00:02:42

tasks from different libs can always count on it being there. nobody can delete it, they can only empty it.

mobileink00:02:05

i think (?) that would make it easier for tasks from different libs to cooperate.

mobileink00:02:51

there's prolly a better way to do this, but it's the best i've been able to come up with

alandipert00:02:01

i have thought this myself, in the past

alandipert00:02:14

the problem is that the contents of this file then introduce the same problem we have now with the fileset

mobileink00:02:07

alandipert: what problem with the fileset?

alandipert00:02:29

except instead of creating/appending to default files, the tasks need to create/append keys in this file

mobileink00:02:03

alandipert: i'm going modern and creating a thread. question: why do files need to be involved? we can just make an api, no? the underlying implementation need not be exposed.

alandipert00:02:02

i guess it depends on your project goals

alandipert00:02:11

files don't need to be involved, in which case you may not even need boot

alandipert00:02:21

in your case, maybe, that is

mobileink00:02:39

we may be cross-talking. what i have in mind is not project-specific.

alandipert00:02:02

what exactly are you trying to optimize for?

alandipert00:02:24

like, what are your goals for boot-gae for example, making it easier to use in some respect?

alandipert00:02:52

asking because discussions like this can be smoother if we have an example in both our minds

mobileink15:02:11

the goal is task interoperability across tasklibs, I guess. for example, the last tasks (`webxml`, appengine) in a boot-gae pipeline write out xml config files (`web.xml`, appengine.xml). They're driven by a config map that gets constructed step by step by previous tasks. the goal is to allow insertion of tasks from other libraries into the boot-gae pipeline. for example, the speechlets task from boot-ask adds info to the config map so that webxml can write out the appropriate servlet stanzas into web.xml. so it has to know about the config map - I call it _boot_config.edn. so anybody who wants to insert a task just needs to read and elaborate bootconfig.edn - and create it, for idempotence. so the idea is that boot could standardize this, so everybody knows that bootconfig.edn (or whatever) is always available.

mobileink19:02:49

@U04VC31U8 sorry to be annoying, just wanted to make sure you saw this.

alandipert19:02:06

saw, haven't had a chance to digest. when i do i'll ping you back

mobileink19:02:46

thx! no rush. not sure my sol'n is good, but task interop is an interesting question anyway, i think.

alandipert00:02:44

so the scoping problem remains, it's just in a different vehicle now. edn instead of fileset

alandipert00:02:59

the bigger problem of ensuring this data is manipulated in the correct order remains

alandipert00:02:30

one thing that you could do, if you want to make your thing more framework-y, is generate a task based on a config file

alandipert00:02:48

i.e. you could have a single task that expects this config file, and then dynamically builds the appropriate task chain

alandipert00:02:53

and returns it

kanwei02:02:13

has anyone written some kind of task to dynamically generate .clj files that are then required from the project?

kanwei02:02:29

I'm trying to get this reloaded workflow working and I'm having issues

flyboarder02:02:12

@kanwei lots of boot tasks do this πŸ™‚

flyboarder02:02:59

if you are just looking to add files to the fileset, I would recommend creating a temp dir writing the file there and then adding the folder to the fileset

kanwei03:02:24

@flyboarder Yeah, I think I got that part to work, it just didn't work when doing a reload with ns-tracker or tools.namespace

kanwei03:02:34

I'll try to get a minimal example case

geoffs04:02:49

@kanwei have you seen this wiki page? https://github.com/boot-clj/boot/wiki/Repl-reloading that might have something to do with why reloading wasn’t working

geoffs06:02:47

I added a new section in the wiki on passing positional parameters to tasks https://github.com/boot-clj/boot/wiki/Task-Options-DSL#positional-parameters

ska12:02:35

@micha, a few days ago you hinted at add-cached-resource which is in boot 2.7.1 and is used in the uber task. Does that mean that I automatically get faster uberjar creation by just updating boot to 2.7.1?

micha13:02:11

@ska those functions were introduced in 2.6.0, but without useful docstrings πŸ™‚

micha13:02:20

we updated the documentation in the next release

micha13:02:51

there are always at least some performance improvements in each release though

sineer14:02:58

I'm trying to get jetty-ring-adapter up and running with boot / boot-http :handler and run into a strange issue I can't figure out: HTTP ERROR: 500 Problem accessing /. Reason: java.lang.Exception: Found lib name 'clojure.pprint' containing period with prefix 'quote'. lib names inside prefix lists must not contain periods, compiling:(NO_SOURCE_PATH:0:0) Powered by Jetty://

sineer14:02:27

... at ring.middleware.reload$wrap_reload$fn__1057.invoke(reload.clj:21)... I can't find any more clue 😞

sineer14:02:54

anyone seen something similar? Or perhaps a working sample I can look at?

micha14:02:38

can you paste a stack trace please?

sineer14:02:03

I searched through the entire target js output for call to pprint and can't find anything, sure i'll paste it on a pastebin

micha14:02:44

that's not a js issue, it's an exception in the jvm, so either clojure or java is thrwoing it

sineer14:02:44

I'm using 1.9.0 alpha14 but I tried with 1.8.0 as well

micha14:02:45

you're probably quoting a symbol inside of the ns macro clauses

micha14:02:50

which confuses it

sineer14:02:03

here's my code with build.boot appended

micha14:02:10

so you want to check your namespace declarations

micha14:02:12

for quotes

sineer14:02:54

I did but perhaps I missed something being tired 😞 there's not much code too only one namespace... that last pastebin is all there is to it

micha14:02:21

have you tried restarting the build?

micha14:02:30

the reload machinery isn't an exact science

micha14:02:35

the ring reload stuff

sineer14:02:52

yeah several time, also tried different clojure version and ring version

micha14:02:04

very strange

sineer14:02:13

yeah I'm stuck πŸ˜•

micha14:02:31

have you tried rolling back to an earlier version of boot-http?

micha14:02:42

maybe the bug is there

sineer14:02:50

no, I'll try that

micha14:02:05

it's unfortunate because the error doesn't say which file is being loaded

micha14:02:18

actually maybe there is a thing

micha14:02:28

well probably not

micha14:02:52

maybe ring reload as some kind of verbose mode

micha14:02:03

where it logs when it attempts to load a file

micha14:02:20

that might help identify the namespaec that has the issue

sineer14:02:04

yeah that last part compiling:(NO_SOURCE_PATH:0:0) is a real bummer 😞

sineer14:02:04

It must be specific to boot-http because when I run the jar file and start jetty manually it works

sineer14:02:20

I did try to downgrade a few minor version of boot-http didn't help

sineer14:02:30

wait I spoke to soon heh, it did fix it after I fixed another issue!

sineer14:02:53

I was missing (gen-class) in my namespace

sineer14:02:27

arr I was wrong it isn't fixed heh 😞

knotschi15:02:29

can I set environment specific variables in the build.boot file that I can use in the clojurescript code? (probably evaluated at compile time)

micha15:02:48

@knotschi you mean something like this: https://github.com/adzerk-oss/env ?

knotschi15:02:12

not sure.. can I set these env vars in my boot tasks?

knotschi15:02:56

and how can I use it in the clojurescript file? (env/env) is only available for Clojure but I cant find anything for ClojureScript? I am confused πŸ˜„

knotschi15:02:33

ah I just found out about goog-define, I guess that works better for me, thanks

micha15:02:56

env/env is in both clojure and clojurescript

knotschi15:02:38

but it sais: ;; clojure only (see https://github.com/adzerk-oss/env/issues/1) (env/env)

micha15:02:59

oh sorry, i meant's env/def

micha15:02:03

that's the thing you want to use

micha15:02:08

env/env is not very useful

raywillig15:02:43

is there a boot builtin that will invoke a -main function the same as if i did java -jar /path/to/jarfile?

richiardiandrea16:02:12

Just a require and a call to your function

pesterhazy16:02:52

for this kind of stuff it would be awesome to have an eval task

pesterhazy16:02:54

boot eval -e '(do (require my.ns) ((resolve 'my.ns/-main)))'

pesterhazy16:02:37

it's basically just a task to "eval this code in a with-passthru block`

pesterhazy16:02:53

perhaps additionally boot eval -m my.ns as a shortcut for that

pesterhazy16:02:34

and boot eval --background -m my.ns runs the function in a future or background task

pesterhazy16:02:38

I know there's boot -i but it's often better to run code in a proper task. This would be handy for one-off tasks from the cli

richiardiandrea16:02:16

I like the idea!

micha16:02:57

boot supports positional parameters in tasks now too though

micha16:02:06

so you can do like

micha16:02:07

(deftask run []
  (with-pass-thru _
    (require 'my.namespace)
    (apply (resolve 'my.namespace/-main) *args*)))

micha16:02:17

and you can pass arguments to main via boot cli like this

micha16:02:33

boot [ run -- foo bar baz ]

micha16:02:43

or via the repl:

micha16:02:59

boot.user=> (boot (run "foo" "bar" "baz"))

micha16:02:35

oh awesome! thanks @geoffs!

geoffs16:02:39

:thumbsup:

richiardiandrea16:02:30

Thanks very helpful to have them in the doc!

geoffs17:02:35

especially since before I edited, the doc explicitly said there was no support for positional parameters πŸ˜„

alandipert18:02:40

written partially in response to the questions here over the years about dev-ing on a build.boot

richiardiandrea18:02:32

the funny thing is that the whole task part could maybe be converted to cljs if we abstracted the pod abstraction πŸ˜„

bhagany18:02:38

ah, great article. It's been fun figuring out the meta-development by experimenting and paying attention here, but I still wish this had been around a few months ago πŸ™‚

bhagany18:02:13

I still feel like I'm doing something wrong by wanting to stay in my repl, though. for instance, I'm running a local fork of boot-http because the latest release doesn't shut down jetty when you ctrl-c in the repl.

bhagany18:02:02

I've hit a few things like that, and it makes me feel like other people aren't trying to do the same things in the repl that I am?

richiardiandrea18:02:09

do you serve you app from boot-http?

bhagany18:02:29

I'm using it with Perun, so I'm just serving up static pages

richiardiandrea18:02:16

kk well I use boot only for developing, so prod for me is exposing a nRepl explicitely

bhagany18:02:50

oh, I see - yeah, I'm just talking about dev-time

bhagany18:02:02

"production" is cloudfront

richiardiandrea18:02:46

oh ok then, yeah ...so in that case isn't the shutdown hook enough for killing jetty?

bhagany18:02:05

yes, I have a PR in with my patch, but it's not merged

pandeiro18:02:05

i've seen it, just haven't had time to merge some other things that were already in the queue - thanks for contributing that though

bhagany18:02:09

heh, sorry, I didn't mean to summon you pandeiro - I didn't want this to be about my PR πŸ™‚

pandeiro18:02:20

no bhagany no problem at all πŸ™‚

alandipert19:02:23

@bhagany an alternative to boot-http is web + serve, as in https://github.com/boot-clj/boot-war-example/blob/master/build.boot

alandipert19:02:43

i'm a huge @pandeiro fan in general, but these days i tend to use web + boot-jetty

pandeiro19:02:36

Yeah I'm also done with boot-http

pandeiro19:02:40

I kid, I kid

alandipert19:02:53

now i feel bad

pandeiro19:02:54

But it's most useful for serving frontend assets really

pandeiro19:02:40

It's a quick way to just run a backend handler, but ultimately, you probably want some more sophisticated logic managing the life cycle of your service (ymmv)

alandipert19:02:41

also i do do boot -d pandeiro/boot-http serve -d . wait all the time

pandeiro19:02:31

the cool thing about lein-ring is that it basically does what boot-http and boot-jetty do, combined - like just serve the handler in dev, then produce the war file for production or whatever

pandeiro19:02:15

I was just reviewing the State of the Artβ„’ with lein, meaning figwheel and luminus, and playing around with them, I felt really grateful that boot exists -- I just love the flexibility and being able to write code rather than enormous configuration maps -- nothing against those two amazing projects

bhagany19:02:59

I think I looked at boot-jetty once, but it seemed like boot-http was used in a bunch of tutorials everywhere. I was on kind of a mission to fix every bug I found for a while there, and the boot-http fix seemed like it would benefit people, so I went for it. I'll be trying out more alternatives as I get more projects under my belt, though

alandipert19:02:05

@pandeiro :thumbsup: it's cool that we have both approaches represented, between lein and boot

richiardiandrea19:02:39

and it is the example I always pull up when somebody asks me, why is it better?

richiardiandrea19:02:07

not to mention that I had a huge classpath conflict once (fortunately fixed quickly)

richiardiandrea19:02:41

but they guys behind lein and figwheel are doing a great job

pandeiro19:02:32

yeah totally, they are great -- but the gigantic configs end up being harder to write/modify than code, i find

pandeiro19:02:24

i mean, i guess you need to understand the more complex boot tasks as well in order to use them... no way around it... but the gigantic project.clj files begin to feel like those XML config files that I dread

richiardiandrea19:02:51

and for easy project I would still choose lein probably, or just use scripts

pandeiro19:02:20

yep, eg lein new compojure my-api produces a very tight, easily understood project

pandeiro19:02:14

relatedly, i wonder if the arachne project will get mindshare and consolidate all this configuration into a basic convention

pandeiro19:02:26

i haven't followed closely enough to have a judgment on that though

richiardiandrea19:02:19

I am so glad they both exists, together with mach and calvin we have many powerful tools at our disposal

richiardiandrea19:02:55

boot is still my favorite though, and I have been playing around a data-centric approach: https://gist.github.com/arichiardi/7e4c430ff4ead706392f22e77c85b16a

richiardiandrea20:02:58

and asking for feedback, actually let me update that

pandeiro20:02:31

that's cool; is there a way to parameterize the generated tasks?

richiardiandrea20:02:10

boot is so flexible that (of course) it allows lein declarative stuff, and improves on that

luke20:02:13

@pandeiro Arachne might step into that role someday; its configuration model is certainly capable of expressing a project configuration. But because I didn’t want to deal with all the attendant bootstrap problems right away, it currently still requires boot/lein/maven/whatever to assemble a classpath and start the JVM.

richiardiandrea20:02:13

yep I have just updated the gist, the macro now supports it

pandeiro20:02:17

@luke Cool yeah I didn't imagine it would do all the dependency resolution; but rather offer something 'batteries included' (for some value of that phrase) that doesn't entail enormous configuration files. I don't know if that is really possible or if I understood correctly the goals of the project; look forward to seeing what you have come up with though!

richiardiandrea20:02:51

isn't the boot repl inheriting env vars? I though it was but:

(java.lang.System/getenv "M2_HOME") ;;=> nil

geoffs20:02:18

@richiardiandrea how did you start your boot repl?

richiardiandrea20:02:31

normal repl -s wait

geoffs20:02:10

interesting. and that env var is definitely defined and exported in that shell?

geoffs20:02:28

just tested, my boot definitely inherits the environment variables

richiardiandrea20:02:32

echo $M2_HOME returns right

richiardiandrea20:02:19

oh ok it was not exported πŸ™€

richiardiandrea20:02:49

funny I have never noticed this before in my .bashrc

richiardiandrea20:02:59

thanks @geoffs !