This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (55)
- # boot (173)
- # clara (3)
- # cljs-dev (10)
- # cljsjs (3)
- # clojars (11)
- # clojure (110)
- # clojure-austin (5)
- # clojure-berlin (13)
- # clojure-chicago (2)
- # clojure-dusseldorf (3)
- # clojure-france (24)
- # clojure-italy (4)
- # clojure-portugal (1)
- # clojure-russia (60)
- # clojure-serbia (8)
- # clojure-spec (150)
- # clojure-uk (129)
- # clojurescript (87)
- # core-logic (1)
- # cursive (75)
- # datavis (1)
- # datomic (75)
- # devcards (4)
- # dirac (17)
- # emacs (50)
- # events (2)
- # hoplon (9)
- # jobs (4)
- # jobs-discuss (37)
- # lein-figwheel (3)
- # luminus (5)
- # off-topic (54)
- # om (9)
- # om-next (5)
- # onyx (10)
- # perun (11)
- # protorepl (11)
- # quil (2)
- # rdf (2)
- # re-frame (14)
- # reagent (58)
- # ring (13)
- # ring-swagger (10)
- # rum (52)
- # spacemacs (8)
- # test-check (10)
- # untangled (17)
- # yada (34)
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.
tasks from different libs can always count on it being there. nobody can delete it, they can only empty it.
there's prolly a better way to do this, but it's the best i've been able to come up with
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
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.
like, what are your goals for boot-gae for example, making it easier to use in some respect?
asking because discussions like this can be smoother if we have an example in both our minds
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.
thx! no rush. not sure my sol'n is good, but task interop is an interesting question anyway, i think.
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
has anyone written some kind of task to dynamically generate .clj files that are then required from the project?
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
@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?
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 😞
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
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
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
It must be specific to boot-http because when I run the jar file and start jetty manually it works
can I set environment specific variables in the build.boot file that I can use in the clojurescript code? (probably evaluated at compile time)
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 😄
but it sais: ;; clojure only (see https://github.com/adzerk-oss/env/issues/1) (env/env)
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
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
(deftask run  (with-pass-thru _ (require 'my.namespace) (apply (resolve 'my.namespace/-main) *args*)))
^^ all of which is also now documented in the wiki https://github.com/boot-clj/boot/wiki/Task-Options-DSL#positional-parameters
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?
kk well I use
boot only for developing, so prod for me is exposing a
oh ok then, yeah ...so in that case isn't the shutdown hook enough for killing jetty?
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 🙂
@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
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)
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)
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
relatedly, i wonder if the arachne project will get mindshare and consolidate all this configuration into a basic convention
I am so glad they both exists, together with
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
boot is so flexible that (of course) it allows
lein declarative stuff, and improves on that
@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.
@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!
boot repl inheriting env vars? I though it was but:
(java.lang.System/getenv "M2_HOME") ;;=> nil