This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-09
Channels
- # admin-announcements (43)
- # beginners (11)
- # boot (141)
- # cider (48)
- # clojure (82)
- # clojure-canada (1)
- # clojure-dev (1)
- # clojure-norway (20)
- # clojure-russia (6)
- # clojure-uk (12)
- # clojurescript (268)
- # datomic (14)
- # editors (5)
- # euroclojure (5)
- # jobs (2)
- # ldnclj (109)
- # off-topic (7)
- # om (6)
- # other-lisps (3)
- # re-frame (13)
- # reagent (3)
- # sim-testing (5)
- # sydney (1)
@micha: @crisptrutski re by-path — isnt there (:tree fileset) or something? That's what I ended up using. A more public API like thing would probably good though :)
lol wrong window 😛
@mitchelkuijpers: careful!
don’t wanna type something sensitive in there… like I have
@andrewmcveigh: I trust you guys 😛
martinklepsch: yeah having an API in boot.core is probably a good idea, although we haven't really nailed down exactly what the public api of boot is
@micha: Do you have opinion on what boot-cljs options should be task options and what should be set from .cljs.edn? I'm thinking main ns, init-fns and (implicitly) docroot are set in cljs.edn and rest from task options (optimizations, source-map, compiler-options).
@micha: I'm not sure, I see some mentions that compiler options could be set from cljs.edn
I'm not sure, I don't think it's reasonable to change compiler options during autobuild
First I though options could be merged but I now think it would be simpler to define where different options must be set
One cljs task = one compiler
Yeah that could be useful
Also, would be easy to use lazy-graph to order tasks automatically (user would write the task dependencies)
Well, that should be something which should be posssible to do in external lib
I wonder if there is any reason to create the cljs.edn file if it doesn't exist
But it's creating the file in pre-wrap so other tasks wont see it?
it needs fileset
Maybe, but I also want to minimize anything which could be changed by changes in Cljs
currently boot-cljs only using cljs.build.api, cljs.env (which should be okay though it isn't a api ns) and cljs.analyzer which might break anytime
and the ordering stuff is reading compiler env directly which is bad
can't we keep our own sanity by just sticking to something that works until there is a clear path forward?
Well, I'll be using latest cljs but yeah I'm okay using something that works until there is something clearly better
I did check the ordering stuff yesterday and I didn't see way to currently do the same using public api
So once boot-cljs is otherwise cleaned I might take another look at that and see what it would require in cljs end to make it work
or we could just improve upstream cljs
but like a proposal that hasn't been in production and proven to be useful will waste a lot of our time in discussion
Yeah it could work both ways, the library would mimick cljs api for old cljs versions and work as template to find new api functions
which is what bhaumans clojurescript-build does, I think
At least many functions cljs api seemed to be directly copied from there
there is some functions for macro reloading in public api
or not for reloading, but for checking if there are any cljs namespaces which depend on macros on a clj ns
and then you can do the actual reloading how ever you want
back to cljs.edn, would it be reasonable to remove default cljs.edn and warn user that other tasks can't add their stuff it cljs.edn doesn't exist?
as it, afaik, doesn't even work currently
I don't see how the other tasks could see the default cljs.edn
But tasks after cljs in the pipeline are run after cljs compilation is done
Right
Maybe
I'm thinking cljs task would have :id option which would select the cljs.edn file
@micha: Perhaps it would be simplest if cljs task always wrote .cljs.edn, in addition to properties already in file, it could write compiler options etc. there for debugging and for other tasks
Though is there a good reason to use file instead of just metadata on fileset?
Except for initial data
yeah i really like the idea of haivng a file that describes the parameters of the build in some abstract way
Should there be an API for other tools which need to read/manipulate cljs.edn or should boot-cljs presume that others know how to do that manually?
or separate ns?
if filesystem meta can serve the purpose that would be a really elegant solution i think
the plugin after all doesn't have dependencies
I doubt there is any dependency issues if there is separate ns (adzerk.boot-cljs.api) which would probably depend only on boot.core
Pff, I would like to finish perun/endophile/pegdown changes but Pegdown developer doesn't seem to be active :S
(https://en.wiktionary.org/wiki/pff#English I did check that pff is valid interjection)
was able to get a script working easily, but noticed dosh and sh don't allow for passthrough of opts to conch. seems like it'd be nice to be able to pass the stdin reader into each process for interactive stuff.
iirc there's a dynamic var you could use to achieve this
oh nvm, that's *sh-dir*
but anyways, you could drive conch more directly through boot.from.me.raynes.conch
, the vendored version of it
using the sh/dosh implementations as a starting point
would that help?
possibly, i haven't even used it in anger yet, so I can't say i'm fully informed, but this was the first thing i tried to do with boot and the first issue i hit with it.
it seems like being able to specify opts to conch would give all the extensibility you'd want.
and a dynamic var is fine for that, since it's using futures or synchronous and those values get conveyed.