I added (sift :move {#"\.cljs$" "ion/poly/$1"}) between (pom) and (jar) and it errors out

clojure.lang.ExceptionInfo: java.lang.IndexOutOfBoundsException: No group 1

oh

you need to make a capturing group in the regex

(sift :move {#"(^.*\.cljs)$" "ion/poly/$1"})

something like that

rock'n'roll!

you rock, micha!

haha thanks!

🎸

alandipert rocks, too!

ok, so in this build.boot file, since I'm just creating a jar, the dependency stuff is just going into the pom.xml file so that consumers of ion/poly will know that they need to resolve these dependencies, is that right?

(set-env!
  :dependencies '[[org.clojure/clojurescript "0.0-3308"]
                  [org.clojure/core.async "0.1.346.0-17112a-alpha"]])

pkobrien: yup!

whadya know, I'm actually learnin

altho, it's up for debate whether libraries should depend on the version of the language they were written against

you may consider omitting the explicit cljs dependency, and just assume consumers of your cljs library are using a cljs compiler of their own choosing

or [org.clojure/clojurescript "0.0-3308" :scope "provided"] is another option

i'm not sure anymore if that really helps though

yeah, was going to ask about that

So how do developers manage working on a library locally as far as installing to a local maven and such where the files need to be deleted or the minor version number changed frequently?

Is there an elegant way to delete the existing jar from the local maven repo before recreating it?

pkobrien: why delete it?

the maven client handles things pretty well in my experience

you can use SNAPSHOT versions, which have built-in affordances for that kind of thing

oh, ok. Did I need to delete it before because it was borked?

the .m2 directory is a local cache

and it stores metadata about the things in the cache

which can sometimes get corrupted

maven is complicated

so when it's failling for no good reason a lot of times it helps to blow out the cache

Okay, but otherwise I can rerun boot pom jar install for the same version and it will update what's in the .m2 cache?

sure

And what does SNAPSHOT buy me, or should I RTFM?

snapshots are like the name, they're snapshots of a version that's still being developed

maven artifacts want to be immutable

meaning you don't reinstall a version

of course you can do it

and it's fine

the SNAPSHOT thing is treated specially by maven, it lets you deploy multiple artifacts to the repo with the same "coordinates"

the maven client will look in the repo metadata to see which snapshot is the latest

and use that

but the earlier snapshots are not deleted,

new snapshots exist alongside them

just like in git, HEAD points to a commit

when you make a new commit HEAD just points to a different commit, but the old HEAD isn't deleted

that's what you get when you declare a version like "1.2.3-SNAPSHOT"

in this way i suppose a snapshot version is like a branch, non-snapshots are like tags

it's a little weird because like if you move a tag it doesn't delete the commit that tag pointed to

but if you reinstall a non-snapshot version it replaces the old artifact

and the old one is no longer reachable

cool

I think I'm good to go for a while. Thanks. And on the consuming side I'm doing [ion/poly "LATEST"] so I'm kind of forced to keep up with my ion/poly library development, at least for now.

gotta save some energy so I can work on cljs-repl one of these days...

aweet!

i ran into problems with trying to use "LATEST", not sure why

if you run into issues where it doesn't find the thing, i found that using "(0,)" sometimes works

First time boot user. Updated JVM options for heap and permspace, but still getting out of memory errors when I run boot dev on an empty reagent project.

Fixed: I didn't know export was specific to one terminal session.

So, I added another library to decomplect/ion and changed my boot file: https://github.com/decomplect/ion/blob/master/build.boot

The cuss library has a macros.clj file so I need to change the re used by sift: (def +re-clj-files+ #"(^.*\.cljs)$")

I was thinking it should pick up files with extensions: clj, cljs, or cljc

Any re gurus lurking?

#"(^.*\.clj[cs]?)$” ?

Why are you building two projects from single repo? Why do you have a separate macro file?

Why not build more than one project from a single repo?

Because you need regex 😄 (Unnecessary complexity for no gain)

If they share some resources it would be justified

@petrus: if you can upgrade to jdk8 you don't have to worry about the memory settings

They are all cljs libraries. I can use a single build.boot to manage them. I eliminate recreating the same directory structure in a bunch of separate repositories. I wouldn't call that no gain.

#"(^.*\.(cljs|clj|cljc))$"

or even clj(|c|s)

Oh alejandro already answered that

As for the separate macros.clj file, I thought you couldn't define macros in cljs and they had to be in a clj file?

And about macros file: if the macro is something that the library users will want to use, it is good idea to place it in ion/cuss/core.clj and add (:require-macros ion.cuss.core) to the cljs file. This way the lib users don't need to use :refer-macros/:require-macros.

Yeah you need cljc or clj file but it's best to use same ns as for cljs file

@juhoteperi: Ah, good tip. Thanks.

I was actually going to ask about that.

https://github.com/omcljs/om/blob/master/src/om/core.cljs#L2

then if users do (:require [om.core :as om]) they can access the macros using om alias automatically

But not through :refer (at least yet)

I guess this should be documented in cljs wiki 😄

So does that mean I can or cannot do this in ion/core.cljs:

(:require-macros
   [ion.cuss.core :refer [defbreakpoint]]

I think that should work

nope, something isn't working

https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure#namespaces ah it is described here

I keep getting a No such namespace: ion.cuss.core error

I am getting the following message during boot dev task: WARNING: Different CLJS version via transitive dependency: 0.0-2816 How can I check what is causing this transitive dependency?

I think I figured it out.

Yep, I'm good to go.

@sooheon: sorry, I don't know about that one

@juhoteperi: thanks for your help - everything is working fine now

I like that I can just do boot cuss build and boot poly build

I thought about writing it so that I passed an argument on the command line but that's more work.

sooheon: you can do boot show -p

A simple boot build fails, which is okay, I guess.

sooheon: and boot show -d

those two will show information about dependencies

boot show -p gives me something like: [!] com.google.guava/guava ✘ 18.0 re-frame ✔️ 17.0 reagent

Should I understand that this means guava 18.0 is required by re-frame and 17.0 is required by reagent, and boot is deciding to use the least common denominator 17.0?

I was wrong, I guess it’s that order of vectors matters in :dependencies

sooheon: you are correct about the interpretation of show -p output

boot uses apache Aether

via pomegranate

this is the underlying machinery that powers the maven repository stuff in boot, maven, and leiningen

so dependency resolution is done the same in all of these tools

you can add [reagent "1.2.3" :exclusions [com.google.guava/guava]], which will instruct aether to not use the transitive dependency from reagent

aether is choosing which transitive dependency based on the "distance"

basically it resolves transitive depdendencies as a pre-order traversal

This also means if I order my :dependencies correctly I don’t really have to worry about :exclusions?

so transitive deps that are fewer times removed from the project in terms of transitive "hops" will be chosen over dependencies that are introduced from more remote depedncies

i think maybe in some cases, but since transitive depdenncies is a graph there is no total ordering of :dependencies that can achieve all possible permutations of transitive deps

Yeah depending on specific needs

like you will probably run into the situation where reordering the deps will introduce other unwanted changes

i'm not even sure exactly how the ordering of :dependencies affects the resolution decisions

On the subject of :dependencies, what does :scope “test” that I see in some templates do?

:scope is an annotation you add to a pom when you make a jar you want to distribute via maven

the thing to keep in mind about :scope is that it has no effect whatsoever on the project itself

it is simply an annotation that consumers of your jar will pay attention to

so for example

suppose you have a clojure project, and you use some testing framework during development

you can add [acme/testing "1.2.3" :scope "test"] to your :dependencies

now suppose you publish this project jar to maven

when i use your project in my own :dependencies, i won't pull in acme/testing because you put :scope "test" in the pom

:scope "test" means that the dependency is only needed when developing the project, not when using it from another project

does that make sense?

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

Yes so if I make a jar of my boot project, the ones with :scope test will not be “exported” so to speak

right

but they'll still be in the pom, so tools can inspect that and know things that might be useful

Ok, so it has no effect on boot development behaviour.

“pom” “maven” are more things I need to google

right, in your project that dependency will be included in the jvm classpath

there is also :scope "provided" which says that the dependency is needed at runtime (i.e. by consumers), but it's expected to have been specified explicitly by the consumer

the example they use is the servlet classes

when you make a library that's intended to be used in a servlet container you know that there will already be some version of the servlet classes in the classpath already

so it makes no sense to have a transitive dependency on it

the only thing that could happen there is that it will be ignored

so you can use :scope "provided" to indicate that you need some version of servlet api in the classpath

but you don't cause confusion by adding your version to the transitive deps of the project that already has servlet api provided by the container

like the container can't provide a different version of the servlet API

I think I understand

While I have your ear, I’m also getting temp-dir! was deprecated, please use tmp-dir! instead these types of warnings

I take it these are for developers of the dependencies, not me

you can turn on debug level output with boot -vv ...

you will see stack traces for those warnings

that will show you where those deprecated functions are being called

if you want to make a pull request i'm sure it would be welcome

-vv is really cool

Ok one more

What could cause this error: java.io.FileNotFoundException: Could not locate cljs/env__init.class or cljs/env.clj on classpath: , compiling:(cemerick/piggieback.clj:1:1)

I never specified this piggieback anywhere

ah, that's the cljs compiler

so the cljs compiler needs clojure 1.7.0

you should add a clojure :dependency to your project like :dependencies [[org.clojure/clojure "1.7.0"] ...]`

hm at least according to boot show -p 1.7.0 is the one being used

what does boot --version show?

#Sat Jul 04 01:42:27 CST 2015
BOOT_CLOJURE_VERSION=1.6.0
BOOT_VERSION=2.1.2
#App version: 2.0.0

I just ran boot -u though

you might need to do this

$ BOOT_CLOJURE_VERSION=1.7.0 boot -u

that will configure boot to use clojure 1.7

because boot needs to have clojure already loaded before it can evaluate your build.boot file

so you need to configure the version of clojure that boot itself uses separately from the project build.boot

I see, aside from the project dependency, there’s the clojure that boot needs

if you don't wnat to use 1.7 by default (i don't see why not, though), you can set it for that specific project

$ BOOT_CLOJURE_VERSION=1.7.0 boot -V > boot.properties

in the project dir

that will pin the version of boot and clojure for that project

it's kind of a good idea to do this if you're doing continuous deployment especially

because it ensures that you know exactly which version of boot will be building your project

you can have the boot.properties file in source control

Aha so moving back in time also adjusts boot’s properties

how do you mean?

With the source control

If I want to go back to a previous point in time, boot’s “environment” is also adjusted

also like suppose you define a task foo in your build.boot file

boot refers vars from the boot.core namespace into the boot.user namespace (your build.boot file)

so it's possible that boot.core/foo may be added someday

that could break your build, possibly

we're working on a way to ensure that doesn't happen

but like for automated builds it seems like a good idea to fix the version of everything

Got it

Boot is pretty freaking awesome

haha that's great to hear

Thanks for your help, really appreciate it

I may have many many more dumb questions

np! it's my pleasure

Is there a complement to :exclusions in :dependencies, like :only?

i don't think so, but that would be a good idea

Hm, micha, the BOOT_CLOJURE_VERSION mandating through boot -u doesn’t stick

you did BOOT_CLOJURE_VERSION=1.7.0 boot -u?

it keeps reverting to 1.6.0, even when I manually edit boot.properties

yep

hmm

one sec i see if i can reproduce

sooheon:ku-live% BOOT_CLOJURE_VERSION=1.7.0 boot -u
#
#Sat Jul 04 02:01:26 CST 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.1.2
#App version: 2.0.0
WARNING: update already refers to: #'clojure.core/update in namespace: clj-http.client, being replaced by: #'clj-http.client/update

very next boot -u will show 1.6.0

oh, that makes sense

boot -u is resetting the defaults

OK, so it’s me doing boot -u with no arguments

that’s causing this

hahah

well it's not having the environment variable set

if you put export BOOT_CLOJURE_VERSION=1.7.0 into your bashrc or whatever

then you can do boot -u without overwriting the clojure version with the default

Ok

here is another error, which I thought was caused by the boot_clojure_version

clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: No single method: _setup of interface: cljs.repl.IJavaScriptEnv found for function: -setup of protocol: IJavaScriptEnv, compiling:(cemerick/piggieback.clj:149:5)
     java.lang.IllegalArgumentException: No single method: _setup of interface: cljs.repl.IJavaScriptEnv found for function: -setup of protocol: IJavaScriptEnv

This only occurs when trying to call re-com in :dependencies

I’ll look into the version of piggieback that re-com introduces, which seems to be the problem

Got it—re-com was calling in an outdated dependency. boot show -d really helps :)

sweet!

dependency issues are a pain in the butt

@sooheon: These are the latest versions of various dependencies that I have in my boot file, fwiw:

:dependencies '[
    [adzerk/boot-cljs           "0.0-3308-0"      :scope "test"]
    [adzerk/boot-cljs-repl      "0.1.10-SNAPSHOT" :scope "test"]
    [adzerk/boot-reload         "0.3.1"           :scope "test"]
    [boot-cljs-test/node-runner "0.1.0"           :scope "test"]
    [pandeiro/boot-http         "0.6.3-SNAPSHOT"  :scope "test"]
    [org.clojure/clojurescript "0.0-3308"]
    [org.clojure/core.async "0.1.346.0-17112a-alpha"]

boot-cljs-repl is the source of some errors and needs some lovin' - I'm hoping I have time in the next couple of days to help with that

@alandipert: I've got boot-cljs-repl working pretty well here:

C:\Users\Patrick\code\ing\informing [master +1 ~1 -0 !]> boot repl -c
REPL-y 0.3.5, nREPL 0.2.10
Clojure 1.7.0
Java HotSpot(TM) Client VM 1.8.0_45-b15
        Exit: Control+D or (exit) or (quit)
    Commands: (user/help)
        Docs: (doc function-name-here)
              (find-doc "part-of-name-here")
Find by Name: (find-name "part-of-name-here")
      Source: (source function-name-here)
     Javadoc: (javadoc java-object-or-class-here)
    Examples from : [clojuredocs or cdoc]
              (user/clojuredocs name-here)
              (user/clojuredocs "ns-here" "name-here")
boot.user=> (start-repl)
<< started Weasel server on ws://127.0.0.1:53326 >>
<< waiting for client to connect ... ←[1mConnection is ws://localhost:53326
←[m←[1mWriting boot_cljs_repl.cljs...
←[m connected! >>
To quit, type: :cljs/quit
nil
cljs.user=> (doc inc)
-------------------------
cljs.core/inc
([x])
  Returns a number one greater than num.
nil
cljs.user=> (in-ns 'app.core)
nil
app.core=> 

@alandipert: So if you still wanted to add me as a maintainer on boot-cljs-repl I can get these changes applied. And I'll need some hand-holding with pushing this out to clojars. And I can work on boot-cljs-example if you want as well.