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.

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

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

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

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

i have thought this myself, in the past

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

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

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

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

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

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

and returns it

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

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

@kanwei lots of boot tasks do this 🙂

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

@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

I'll try to get a minimal example case

@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

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

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

@ska those functions were introduced in 2.6.0, but without useful docstrings 🙂

we updated the documentation in the next release

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

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://

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

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

can you paste a stack trace please?

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

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

throwing

https://www.refheap.com/124950

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

looks like you have this problem in one of your clojure namespaces: http://stackoverflow.com/questions/17854261/lib-names-inside-prefix-lists-must-not-contain-periods

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

which confuses it

here's my code with build.boot appended

https://www.refheap.com/124952

so you want to check your namespace declarations

for quotes

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

have you tried restarting the build?

the reload machinery isn't an exact science

the ring reload stuff

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

very strange

yeah I'm stuck 😕

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

maybe the bug is there

no, I'll try that

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

actually maybe there is a thing

one sec

well probably not

maybe ring reload as some kind of verbose mode

where it logs when it attempts to load a file

that might help identify the namespaec that has the issue

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

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

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

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

I was missing (gen-class) in my namespace

aha

arr I was wrong it isn't fixed heh 😞

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

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

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

yes

https://github.com/adzerk-oss/env#get

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 😄

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

env/env is in both clojure and clojurescript

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

oh sorry, i meant's env/def

that's the thing you want to use

env/env is not very useful

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

@raywillig no built in because it is trivial I guess: https://github.com/Lambda-X/lambone/blob/master/resources/leiningen/new/lambone/common/dev/boot.clj#L106

Just a require and a call to your function

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

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

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

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

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

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

I like the idea!

@raywillig also https://github.com/boot-clj/boot/wiki/Boot-for-Leiningen-Users#lein-run

boot supports positional parameters in tasks now too though

so you can do like

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

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

boot [ run -- foo bar baz ]

or via the repl:

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

^^ all of which is also now documented in the wiki https://github.com/boot-clj/boot/wiki/Task-Options-DSL#positional-parameters

oh awesome! thanks @geoffs!

:thumbsup:

Thanks very helpful to have them in the doc!

especially since before I edited, the doc explicitly said there was no support for positional parameters 😄

hey all i thought this would interest you, https://adzerk.com/blog/2017/02/faster-clojure-metadevelopment-with-boot/

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

the funny thing is that the whole task part could maybe be converted to cljs if we abstracted the pod abstraction 😄

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 🙂

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.

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?

do you serve you app from boot-http?

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

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

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

"production" is cloudfront

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

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

https://github.com/pandeiro/boot-http/pull/59

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

heh, sorry, I didn't mean to summon you pandeiro - I didn't want this to be about my PR 🙂

no bhagany no problem at all 🙂

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

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

Yeah I'm also done with boot-http

I kid, I kid

now i feel bad

But it's most useful for serving frontend assets really

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)

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

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

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

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

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

@pandeiro I started using boot because of this: https://github.com/Lambda-X/replumb/blob/master/project.clj

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

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

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

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

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

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

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

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

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

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

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

and asking for feedback, actually let me update that

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

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

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

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

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

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

@richiardiandrea how did you start your boot repl?

normal repl -s wait

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

just tested, my boot definitely inherits the environment variables

echo $M2_HOME returns right

uhm..

oh ok it was not exported 🙀

funny I have never noticed this before in my .bashrc

thanks @geoffs !