Fork me on GitHub
#boot
<
2015-10-30
>
micha00:10:54

@jfntn: like this

micha00:10:05

the minimal viable thing:

jfntn00:10:54

hmm ok I don’t have a core file

micha00:10:14

you can name your files whatever you want

micha00:10:27

this is just an example of compiling some cljs to js

micha00:10:35

boot doesn't know what your namespaces are

micha00:10:01

basically if you have some directory, let's say it's named src

micha00:10:10

and that has cljs namespace source files in it

micha00:10:25

you just type boot -s src -d adzerk/boot-cljs cljs

micha00:10:30

you don't even need a build.boot file

micha00:10:56

that will compile your clojurescript and emit javascript into the target dir, which is by default target

jfntn00:10:31

@micha: ah indeed you’re right, this is actually coming from boot-cljs-test

sjm02:10:47

@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

alandipert02:10:44

@sjm: does not include snapshots, but releases almost never depend on snapshots

alandipert02:10:05

so in practice, it's not something to worry about (unless you yourself choose to depend on snapshots)

sjm02:10:15

hence the slippery slope simple_smile

alandipert02:10:51

somewhat slipper-ier in boot... since you can add dependencies at any time. but we like it, we have kneepads on simple_smile

alandipert02:10:47

also the complexity inherent in the dynamism is mitigated by pods, craziness can be easily isolated

sjm02:10:01

Haha, ah you mean runtime deps... yeah that the scourge I banish to the cellar. It will totally break my setup simple_smile

sjm02:10:22

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)

domkm03:10:26

Is there a way to concurrently run both a CLJ REPL and a CLJS REPL with one task?

alandipert04:10:59

you could connect to the same repl server from multiple clients, no?

domkm04:10:00

That is a good point simple_smile I'm sure that would work, thanks.

domkm06:10:56

Is there a way to configure boot-cljs to output to a particular location without using a .cljs.edn file?

domkm06:10:30

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.

isaac06:10:01

which is the suggested. use boot launch app, or boot uber jar and then java -jar app.jar

martinklepsch08:10:00

@domkm: is there a reason you don't want to have a cljs.edn?

martinklepsch08:10:45

@isaac: Both are fine and have their own tradeoffs.

micha10:10:46

@sjm just read your post about contracts vs versioning

micha10:10:56

very interesting

micha10:10:51

any advice you have regarding boot versioning etc would be much appreciated

alandipert10:10:31

it was awesome

alandipert10:10:41

i wondered about something in between, a multidimensional version

alandipert10:10:53

with axes like "stability" and "fileset performance"

alandipert10:10:33

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

sjm13:10:05

@micha @alandipert read the section of Evolution of Public Contracts here: http://rfc.zeromq.org/spec:22

micha13:10:37

one of the things that's hard to do is even nail down the public API

micha13:10:47

i think getting metrics will help a lot there

micha13:10:04

if we can get people to let us collect usage stats

micha13:10:24

we can know what's being used and what isn't

micha13:10:45

so we can intelligently map out which things need to be in the contract and which don't

martinklepsch13:10:54

@micha: will rebase the branch against master now

martinklepsch13:10:21

The ZeroMQ logo is awesome

micha13:10:02

oh ok cool

micha13:10:22

can you squash it as well?

micha13:10:49

i don't see any merges in there, it should squash without too much trouble

micha13:10:05

lol "squash"

micha13:10:11

funny word

martinklepsch13:10:55

yes I can squash, have you tested?

micha13:10:03

when you're ready i'll test and merge

micha13:10:45

i like your (boot pod install) stuff in the makefile

micha13:10:49

very lispy

micha13:10:06

the parens confused me for a second

micha13:10:57

we could generate version.properties from that

martinklepsch13:10:20

@micha: I took that format from your previous Makefile, I have no clue about make

micha13:10:39

well i like it

micha13:10:50

very stylish Makefile

martinklepsch13:10:34

@micha: think I got it

micha13:10:50

sweet, i'm ready when you are

martinklepsch13:10:09

but for what? 😄

micha13:10:13

ok i will pull now

micha13:10:45

compiling....

martinklepsch13:10:29

I’m not sure how we should test pushing, maybe we push a snapshot?

micha13:10:33

yeah, perhaps

micha13:10:58

snapshots won't affect any users

martinklepsch13:10:41

I think we should push more often anyways (snapshots/git releases)

micha13:10:51

there's like 500ms difference in startup time

micha13:10:02

i think we're missing some namespaces with the AOT

martinklepsch13:10:10

oh that could be

micha13:10:12

but it totally builds

martinklepsch13:10:38

(aot :namespace #{'boot.cli 'boot.core 'boot.git 'boot.main 'boot.repl
                          'boot.task.built-in 'boot.task-helpers 'boot.tmregistry})

martinklepsch13:10:44

This isn’t what we want really

micha13:10:57

also since boot has its own dependency tracking via the pick task etc

micha13:10:06

we probably don't need to involve make anymore

micha13:10:03

if there are weird issues with race conditions in watch mode we can just run certain tasks in pipeline order before calling the runboots

micha13:10:17

like to prepare

martinklepsch13:10:33

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

micha13:10:47

yeah we can do that, no?

martinklepsch13:10:05

yeah, I guess we could have a task that runs the runboot stuff

micha13:10:24

like do it in two phases, do thingsin whatever order, then runboots all at the same time

micha13:10:06

i have an idea

pesterhazy13:10:16

How do people access their`pom` :version at runtime?

micha13:10:21

we can add an event system to boot.App

micha13:10:44

@pesterhazy: you def a var named version and pass it into pom and whatever eles

pesterhazy13:10:27

I already do that

pesterhazy13:10:37

@micha, I meant from inside the code running in the .jar

micha13:10:42

so you just reference that var, no?

micha13:10:00

you can make a version.edn file

martinklepsch13:10:05

I think he means like running an uberjar and getting the pom version

micha13:10:11

and add it to the jar's classpath

micha13:10:25

or look in META-INF etc

pesterhazy13:10:26

yeah, like @martinklepsch says

micha13:10:31

for the pom.properties file

pesterhazy13:10:39

edn in classpath sounds like a good idea

martinklepsch13:10:00

@pesterhazy: you can create this edn file with a task that uses the version thing defined in your build.boot

martinklepsch13:10:20

Then you don’t have to change things twice 😉

pesterhazy13:10:40

@martinklepsch: I could ... if I knew how simple_smile

martinklepsch14:10:05

@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

martinklepsch14:10:06

(deftask add-version-edn []
  (with-pre-wrap fs
    (let [t (tmp-dir!)]
      (spit (io/file t “version.edn” …)
      (-> fs (add-resource t) commit!))))

martinklepsch14:10:11

@pesterhazy: ^

pesterhazy14:10:49

that's a defn, not a deftask, correct?

martinklepsch14:10:32

@pesterhazy: everything using with-pre-wrap is usually in a deftask.

pesterhazy14:10:01

(some-> "version.txt"  slurp clojure.string/trim) 

martinklepsch14:10:09

you could also just insert the with-pre-wrap form into your task pipeline without defining it as an actual task

martinklepsch14:10:59

when pushing snapshot releases to clojars is the only way clojars detects a snapshot that the version ends with snapshot?

martinklepsch14:10:30

If not it might be cool to push every commit as snapshot release with git describe versioning

micha14:10:18

yeah the -SNAPSHOT version is part of the maven spec

pesterhazy14:10:18

does maven support git hashes as valid version numbers?

micha14:10:22

well it's not exactly a spec

micha14:10:32

but it's what maven does, so it's pretty much a standard

micha14:10:47

@pesterhazy: yes, and no

micha14:10:57

you can use any string you want as a version

martinklepsch14:10:05

then we could still do (git describe)-SNAPSHOT, i.e. 2.4.2-7-gd5d35a4-SNAPSHOT

micha14:10:09

but maven won't know how to interpret it

micha14:10:23

so it can't know if one sha is later than another

micha14:10:27

which stands to reason

micha14:10:44

martinklepsch: yep

pesterhazy14:10:46

I guess maven predates the nonsequential versioning of git

micha14:10:36

i don't see any advantage to nonsequential versions, what would the benefit be?

micha14:10:56

how do people resolve conflicts with opaque versions?

pesterhazy14:10:30

well git hashes are hashes of the contents, which has obvious advantages

micha14:10:58

what advantages?

pesterhazy14:10:59

that they are not sequential (vs svn or hg) is just a sad by-product

micha14:10:27

like when i depend on a library i don't care about the contents of the source code as text

micha14:10:32

i care about the interface

micha14:10:38

and the contracts involved

pesterhazy14:10:56

for that, you need actual version numbers with meaning (and sequential)

micha14:10:18

i think that's the most critical piece of the entire software ecosystem

micha14:10:38

you need to be able to form abstractions on top of other people's work that encapsulates it

micha14:10:49

so your consumers don't need to know about the transitive deps

micha14:10:06

and if a conflict arises, it should be possible to resolve without deep knowledge of the transitive deps

pesterhazy14:10:16

I didn't mean to defend having no version numbers

pesterhazy14:10:44

I agree with what you say

micha14:10:18

versions are hard, too simple_smile

micha14:10:06

@martinklepsch: how can i reproduce the timing issue with the boot build?

martinklepsch14:10:33

what timing issue? aether uber thing?

martinklepsch14:10:41

make clean; boot build

micha14:10:44

cool i will try it

micha14:10:55

i was thinking about adding an event queue to boot.App

micha14:10:06

so we could have a task that sends an event

micha14:10:12

and a task that waits on an event

pesterhazy14:10:35

Putting version.txt in the classspath worked fine

micha14:10:44

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

pesterhazy14:10:00

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

micha14:10:41

👍 nice!

pesterhazy14:10:04

is there a place for snippets like these?

martinklepsch14:10:29

If not create a snippets page in the wiki simple_smile

micha14:10:44

@pesterhazy: awesome thank you

martinklepsch15:10:16

@pesterhazy: ^ would love your thoughts simple_smile

martinklepsch15:10:35

And anyone else’s too of course simple_smile

pesterhazy15:10:44

TBH, I'm inclined to say OSS projects shouldn't track user behavior at all

pesterhazy15:10:14

IMO free software should be a "safe zone" where you don't have to worry about these things

pesterhazy15:10:40

of course if it's strictly opt-in, that's fine

pesterhazy15:10:24

e.g. as a separate plug-in

pesterhazy15:10:17

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

micha15:10:54

it's true though that nobody seems to mind github recording stats and displaying them

micha15:10:19

seems like a similar situation

martinklepsch15:10:45

github is a commercial service, in addition to that it’s a website where tracking is much more accepted/usual.

pesterhazy15:10:11

right, I'm sure whoever runs maven, npm, pip etc. keeps stats

pesterhazy15:10:48

but that's server-side, not an explicit "phoning home" feature where no network request would normally be required

micha15:10:47

i wonder if maybe we want a public service for OSS stats

micha15:10:28

i guess the reason why it's ok for github is because it's a website and people are accustomed to that

micha15:10:43

if we had a website, like http://statshub.com or something

micha15:10:55

that would just add to the stats for repos

micha15:10:07

it might not seem like such a new weird thing

micha16:10:01

like if anyone can use it in their own projects

domkm16:10:09

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

martinklepsch16:10:25

@domkm: that’s exactly what .cljs.edns are intended for. (Sorry for the non-answer earlier btw.)

domkm16:10:28

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.

martinklepsch16:10:49

@domkm: you might want different optimizations for different builds, different compiler options, different init fns

domkm16:10:02

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

martinklepsch16:10:31

what are the things you want to change depending on the environment?

martinklepsch16:10:09

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

domkm16:10:29

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)

martinklepsch16:10:15

all things you mentioned can be configured with tasks

domkm16:10:44

So, to clarify, the official way to achieve this is to write a pre task that modifies the .cljs.edn file?

martinklepsch16:10:13

if you want to modify requires based on some parameter, yes

juhoteperi16:10:04

@domkm: Multiple builds solves a bit difference problem than Closure modules, I think

martinklepsch16:10:54

@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

juhoteperi16:10:56

I'm using multiple builds to build separate app, tests and perhaps devcards app

juhoteperi16:10:44

But yeah, completely separate builds is not an optimal solution but Closure modules are useless for development situations

domkm16:10:15

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?

domkm16:10:59

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

martinklepsch16:10:58

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.

martinklepsch16:10:00

Another useful case would be injecting things like cljs-devtools into your build: https://github.com/binaryage/cljs-devtools

juhoteperi16:10:24

@domkm: boot-cljs runs the builds parallel

juhoteperi16:10:29

But it should be possible to create a task which can run tasks given to it parallel

martinklepsch16:10:53

Yeah think so too

juhoteperi16:10:42

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.

juhoteperi16:10:00

Perhaps ClojureScript compiler should write shims for each module.

martinklepsch16:10:38

> Mostly the multiple builds stuff exists for Hoplon. Not sure I agree. Has also been super useful with Electron.

juhoteperi17:10:17

I think in most cases it would be just as easy to add another cljs to the pipeline.

martinklepsch17:10:00

are we talking of multiple builds as in .cljs.edn files?

juhoteperi17:10:00

@martinklepsch: Not directly. More about single Cljs task handling multiple builds instead of having cljs task for each cljs.edn file.

juhoteperi17:10:16

But there is definitely pros for cljs task handling several files.

juhoteperi17:10:29

Like you can add new cljs.edn files without restarting etc.

domkm17:10:29

@martinklepsch: devtools is one of the things I want to inject in the dev build 😉

domkm17:10:44

Got it. Thanks for the help and discussion @martinklepsch and @juhoteperi

martinklepsch17:10:13

@domkm: put the task that injects cljs-devtools on github simple_smile

martinklepsch17:10:55

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

domkm17:10:48

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

domkm17:10:53

Gotta run, thanks again.

jfntn17:10:19

Has anyone managed to run boot-cljs-test with nodejs?

jfntn17:10:24

I have a test-suite passing in phantom, but the node runner complains about a namespace issue

anthgur18:10:56

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

martinklepsch18:10:54

@anthgur: update your homebrew installation. Gotta run, hope that helps.

micha18:10:08

@martinklepsch: i have a thing

micha18:10:15

can i push to the boot-in-boot branch?

micha18:10:22

i guess i can make a new branch

anthgur18:10:02

...I restarted my computer and it now works

martinklepsch18:10:52

@micha whatever you prefer

jfntn18:10:14

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?

jgdavey20:10:52

@briandunn: there are many ways to add repositories for reconciling dependencies, but in general they must conform to Maven

jgdavey20:10:48

To get a local dependency recognized, the easiest way is to install it to your local Maven repository (usually ~/.m2)

jgdavey20:10:43

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.

briandunn20:10:40

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

jgdavey20:10:49

However, I’m not aware of any way to use boot (or anything that uses Maven dependency management) like that.

jgdavey20:10:28

Could you add that project to your resource-paths while editing?

briandunn20:10:52

I'll try it.

jgdavey20:10:53

Perhaps someone else here has a idea for this kind of development cycle.

alandipert20:10:21

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

briandunn20:10:38

@alandipert: thanks! I'll take a look.

briandunn20:10:06

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

alandipert20:10:28

that's what i usually do

alandipert21:10:00

the checkouts approach is more useful when A's build does stuff like compile java

briandunn21:10:54

Word. I'll keep that in mind.