This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-30
Channels
- # admin-announcements (11)
- # announcements (1)
- # beginners (1)
- # boot (247)
- # cider (15)
- # clara (16)
- # cljs-dev (14)
- # clojure (118)
- # clojure-czech (10)
- # clojure-ecuador (1)
- # clojure-japan (1)
- # clojure-russia (22)
- # clojurescript (57)
- # data-science (12)
- # datomic (2)
- # devcards (1)
- # editors-rus (2)
- # emacs (1)
- # events (2)
- # funcool (1)
- # hoplon (37)
- # juxt (1)
- # ldnclj (2)
- # leiningen (1)
- # nginx (12)
- # off-topic (16)
- # om (361)
- # onyx (34)
- # re-frame (3)
- # spacemacs (9)
- # yada (43)
that will compile your clojurescript and emit javascript into the target dir, which is by default target
@micha: "micha [2:44 AM] versioned artifacts protect you from the transitivedependency problem like the dependency graph is deterministic" -> does this include SNAPSHOTS? My opinion on software versions in general: http://hintjens.com/blog:85
@sjm: does not include snapshots, but releases almost never depend on snapshots
so in practice, it's not something to worry about (unless you yourself choose to depend on snapshots)
somewhat slipper-ier in boot... since you can add dependencies at any time. but we like it, we have kneepads on
also the complexity inherent in the dynamism is mitigated by pods, craziness can be easily isolated
Haha, ah you mean runtime deps... yeah that the scourge I banish to the cellar. It will totally break my setup
I'll stick with making my boot nix expression with the boot.jar file. But this will still get me from time to time? (https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/main.clj#L90-L94)
you could connect to the same repl server from multiple clients, no?
surely
Is there a way to configure boot-cljs to output to a particular location without using a .cljs.edn file?
I suppose I could write a task to dynamically output a .cljs.edn file and run it before the cljs one runs, but that seems hacky.
which is the suggested. use boot launch app, or boot uber jar
and then java -jar app.jar
@domkm: is there a reason you don't want to have a cljs.edn?
@isaac: Both are fine and have their own tradeoffs.
it was awesome
i wondered about something in between, a multidimensional version
with axes like "stability" and "fileset performance"
because we have a good idea now the directions we want to improve in, so presumably we could be clear about what progress is made in those directions and what regressions/incompatibilities the progress introduces
@micha @alandipert read the section of Evolution of Public Contracts
here: http://rfc.zeromq.org/spec:22
so we can intelligently map out which things need to be in the contract and which don't
@micha: will rebase the branch against master now
The ZeroMQ logo is awesome
yes I can squash, have you tested?
did you see what i did with boot-bin, btw? https://github.com/boot-clj/boot-bin/blob/master/build.sh#L6
@micha: I took that format from your previous Makefile, I have no clue about make
@micha: think I got it
but for what? 😄
I’m not sure how we should test pushing, maybe we push a snapshot?
I think we should push more often anyways (snapshots/git releases)
oh that could be
(aot :namespace #{'boot.cli 'boot.core 'boot.git 'boot.main 'boot.repl
'boot.task.built-in 'boot.task-helpers 'boot.tmregistry})
This isn’t what we want really
if there are weird issues with race conditions in watch mode we can just run certain tasks in pipeline order before calling the runboots
then we need some mechanism for one task to fire when the other is done (in a separate build pipeline) because otherwise we still need to manually run the one that moves the aether uberjar first
yeah, I guess we could have a task that runs the runboot stuff
like do it in two phases, do thingsin whatever order, then runboots all at the same time
How do people access their`pom` :version
at runtime?
@pesterhazy: you def a var named version
and pass it into pom
and whatever eles
I already do that
@micha, I meant from inside the code running in the .jar
I think he means like running an uberjar and getting the pom version
yeah, like @martinklepsch says
edn in classpath sounds like a good idea
@pesterhazy: you can create this edn file with a task that uses the version
thing defined in your build.boot
Then you don’t have to change things twice 😉
@martinklepsch: I could ... if I knew how
@micha: event system to boot.App sounds… ahem… strange? Imo using runboot and orchastrating multiple of them; putting files in magic dirs etc. is already not very clean. The thought of added code to facilitate this makes me sceptical
(deftask add-version-edn []
(with-pre-wrap fs
(let [t (tmp-dir!)]
(spit (io/file t “version.edn” …)
(-> fs (add-resource t) commit!))))
that's a defn
, not a deftask
, correct?
edited
@pesterhazy: everything using with-pre-wrap
is usually in a deftask.
got it
(some-> "version.txt" slurp clojure.string/trim)
you could also just insert the with-pre-wrap
form into your task pipeline without defining it as an actual task
when pushing snapshot releases to clojars is the only way clojars detects a snapshot that the version ends with snapshot?
If not it might be cool to push every commit as snapshot release with git describe
versioning
does maven support git hashes as valid version numbers?
@pesterhazy: yes, and no
then we could still do (git describe)-SNAPSHOT
, i.e. 2.4.2-7-gd5d35a4-SNAPSHOT
I guess maven predates the nonsequential versioning of git
well git hashes are hashes of the contents, which has obvious advantages
that they are not sequential (vs svn or hg) is just a sad by-product
like when i depend on a library i don't care about the contents of the source code as text
sure yes
for that, you need actual version numbers with meaning (and sequential)
you need to be able to form abstractions on top of other people's work that encapsulates it
and if a conflict arises, it should be possible to resolve without deep knowledge of the transitive deps
I didn't mean to defend having no version numbers
I agree with what you say
@martinklepsch: how can i reproduce the timing issue with the boot build?
what timing issue? aether uber thing?
make clean; boot build
Putting version.txt
in the classspath worked fine
so if you have these kinds of dependencies between boot builds you can synchronize them on events passed through boot.App, which they can all interact with
here's the slight adaption:
(deftask add-version-txt []
(with-pre-wrap fs
(let [t (tmp-dir!)]
(spit ( t "version.txt") (get-version))
(-> fs (add-resource t) commit!))))
is there a place for snippets like these?
If not create a snippets page in the wiki
@pesterhazy: awesome thank you
@pesterhazy: ^ would love your thoughts
And anyone else’s too of course
TBH, I'm inclined to say OSS projects shouldn't track user behavior at all
IMO free software should be a "safe zone" where you don't have to worry about these things
of course if it's strictly opt-in, that's fine
e.g. as a separate plug-in
I agree that people tend to have strong feelings about this, so even if you get it right it'll be hard to communicate that to users
github is a commercial service, in addition to that it’s a website where tracking is much more accepted/usual.
right, I'm sure whoever runs maven, npm, pip etc. keeps stats
but that's server-side, not an explicit "phoning home" feature where no network request would normally be required
i guess the reason why it's ok for github is because it's a website and people are accustomed to that
if we had a website, like http://statshub.com or something
@martinklepsch: Yes, I don't want a .cljs.edn file because I want to dynamically determine the requires, init-fns (in dev I want to require additional files that change printing and add util functions), and output-path. I also prefer to have all config in one place (build.boot) but that's a minor issue.
@domkm: that’s exactly what .cljs.edns are intended for. (Sorry for the non-answer earlier btw.)
It seems odd to be that these are not configurable via the cljs task. I could easily be missing the point but I don't really see the purpose of multiple simultaneous builds since we can use modules to support code splitting.
@domkm: you might want different optimizations for different builds, different compiler options, different init fns
@martinklepsch: Could you clarify? How do I have a .cljs.edn file that works for dev, test, staging, prod? I don't need to ever build simultaneously.
what are the things you want to change depending on the environment?
Maybe an example can clarify: if you’ve ever used figwheel you added some dev namespace which you load based on some condition and run some init fn in that namespace. With cljs.edn files this becomes a pluggable mechanism. Tasks can add requires and init functions and this add things like reloading and repl code without requiring you to explicitly manage those things in your application code
optimizations (easy, can be configured with task), compiler-options (easy, can be configured with task), requires (hard, cannot be configured with task), init-fns (hard, cannot be configured with task), output-location (cannot be configured with task but also this isn't dynamic)
all things you mentioned can be configured with tasks
So, to clarify, the official way to achieve this is to write a pre task that modifies the .cljs.edn file?
https://github.com/adzerk-oss/boot-cljs-repl/blob/master/src/adzerk/boot_cljs_repl.clj#L192
if you want to modify requires based on some parameter, yes
@domkm: Multiple builds solves a bit difference problem than Closure modules, I think
@domkm: I think the modification of cljs.edn files can be a five lines task. Maybe that would even be an interesting task to package with boot-cljs
I'm using multiple builds to build separate app, tests and perhaps devcards app
But yeah, completely separate builds is not an optimal solution but Closure modules are useless for development situations
I probably don't fully grok this yet but, if you wanted 2 completely separate builds and the cljs task was completely configurable, couldn't you just use the task twice in the same pipeline?
I'll just go with dynamically modifying .cljs.edn for now and maybe the utility of it will become apparent to be with a bit more use.
I think the main issue with a completely configurable cljs task is that there is no extension point for other tasks like REPL code injection.
Another useful case would be injecting things like cljs-devtools into your build: https://github.com/binaryage/cljs-devtools
@domkm: boot-cljs runs the builds parallel
But it should be possible to create a task which can run tasks given to it parallel
Yeah think so too
Mostly the multiple builds stuff exists for Hoplon. I don't fully grok what it needs but I suspect Closure modules would be useful for it, but it would require some magic to work with no optimizations.
Perhaps ClojureScript compiler should write shims for each module.
> Mostly the multiple builds stuff exists for Hoplon. Not sure I agree. Has also been super useful with Electron.
I think in most cases it would be just as easy to add another cljs to the pipeline.
are we talking of multiple builds as in .cljs.edn files?
@martinklepsch: Not directly. More about single Cljs task handling multiple builds instead of having cljs task for each cljs.edn file.
But there is definitely pros for cljs task handling several files.
Like you can add new cljs.edn files without restarting etc.
@martinklepsch: devtools is one of the things I want to inject in the dev build 😉
Got it. Thanks for the help and discussion @martinklepsch and @juhoteperi
@domkm: put the task that injects cljs-devtools on github
@domkm: also does the cljs.edn stuff make sense to you now? I think I was sceptical myself at first but now think it’s an awesome idea
It makes sense but doesn't feel right yet so I guess I'm still in the skeptical phase. I guess I'll catch up to you guys eventually.
I have a test-suite passing in phantom, but the node runner complains about a namespace issue
$ boot -u
#
#Fri Oct 30 13:56:16 EDT 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.4.2
#App version: 2.2.0
$ boot repl
Please download latest Boot binary:
$
I installed boot before there was a brew formula available. When I go to run it now I get this. I've run brew install boot-clj
and brew brew link --overwrite boot-clj
. Looks like the old version of boot is completely removed too. I've also cleared my ~/.boot
directory. I wasn't sure if this was specific to me and I can't reproduce it so I didn't raise the issue on github. Any thoughts?@anthgur: update your homebrew installation. Gotta run, hope that helps.
@martinklepsch: i have a thing
@micha whatever you prefer
I’m running into issues where boot task1 task2 task 3 task4
fails but running successive invocations of boot taskN
succeeds. Without getting into details would that be enough to hint at using pods instead?
@briandunn: there are many ways to add repositories for reconciling dependencies, but in general they must conform to Maven
To get a local dependency recognized, the easiest way is to install it to your local Maven repository (usually ~/.m2)
Workflow: project B depends on project A. Get project A to where to you want it, then use boot build install
. Whatever version you specify in the project A pom will need to match what you depend on in project B.
@jgdavey: I'm trying to depend on a library I'm working on. want project B to always build against the latest files in project A. is that a thing, or do I have to bump the version of A and reinstall for every change?
However, I’m not aware of any way to use boot (or anything that uses Maven dependency management) like that.
@briandunn: give boot checkout -h
a look... checkout is boot's rough equivalent of lein checkouts, which is for same use case (developing project, lib in tandem)
@alandipert: thanks! I'll take a look.
@jgdavey: I temporarily added the path to my checkout of A in the :source-paths of B. So far it seems to be working perfectly: my working copy of A is the one used by B, not the fetched jar. :thumbsup:
that's what i usually do
the checkouts approach is more useful when A's build does stuff like compile java