Fork me on GitHub
#boot
<
2015-07-03
>
meow00:07:20

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

meow00:07:56

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

micha00:07:10

you need to make a capturing group in the regex

micha00:07:43

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

micha00:07:49

something like that

meow00:07:21

rock'n'roll!

meow00:07:44

you rock, micha! simple_smile

micha00:07:30

haha thanks!

meow00:07:57

alandipert rocks, too!

meow00:07:48

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"]])

micha00:07:08

pkobrien: yup!

meow00:07:57

whadya know, I'm actually learnin

alandipert00:07:23

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

alandipert00:07:32

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

micha00:07:20

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

micha00:07:39

i'm not sure anymore if that really helps though

meow00:07:21

yeah, was going to ask about that

meow00:07:18

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?

meow00:07:01

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

micha00:07:00

pkobrien: why delete it?

micha00:07:23

the maven client handles things pretty well in my experience

micha00:07:45

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

meow00:07:48

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

micha00:07:01

the .m2 directory is a local cache

micha00:07:17

and it stores metadata about the things in the cache

micha00:07:26

which can sometimes get corrupted

micha00:07:31

maven is complicated

micha00:07:49

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

meow00:07:57

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

meow00:07:06

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

micha00:07:32

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

micha00:07:42

maven artifacts want to be immutable

micha00:07:50

meaning you don't reinstall a version

micha00:07:53

of course you can do it

micha00:07:54

and it's fine

micha00:07:33

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

micha00:07:52

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

micha00:07:54

and use that

micha00:07:07

but the earlier snapshots are not deleted,

micha00:07:15

new snapshots exist alongside them

micha00:07:30

just like in git, HEAD points to a commit

micha00:07:47

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

micha00:07:10

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

alandipert00:07:50

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

micha00:07:18

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

micha00:07:40

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

micha00:07:48

and the old one is no longer reachable

meow00:07:49

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.

meow01:07:18

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

micha01:07:49

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

micha01:07:15

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

Petrus Theron11:07:11

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.

Petrus Theron11:07:38

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

meow14:07:54

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

meow14:07:57

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

meow14:07:42

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

meow14:07:12

Any re gurus lurking?

alejandro14:07:36

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

juhoteperi14:07:31

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

meow14:07:34

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

juhoteperi14:07:57

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

juhoteperi14:07:24

If they share some resources it would be justified

alandipert14:07:42

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

meow14:07:44

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.

juhoteperi14:07:29

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

juhoteperi14:07:44

or even clj(|c|s)

juhoteperi14:07:40

Oh alejandro already answered that

meow14:07:34

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?

juhoteperi14:07:13

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.

juhoteperi14:07:31

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

meow14:07:48

@juhoteperi: Ah, good tip. Thanks.

meow14:07:08

I was actually going to ask about that.

juhoteperi14:07:59

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

juhoteperi14:07:13

But not through :refer (at least yet)

juhoteperi14:07:02

I guess this should be documented in cljs wiki 😄

meow14:07:19

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

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

juhoteperi14:07:34

I think that should work

meow14:07:31

nope, something isn't working

meow15:07:20

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

sooheon15:07:49

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?

meow15:07:22

I think I figured it out.

meow15:07:26

Yep, I'm good to go.

meow15:07:49

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

meow15:07:27

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

meow15:07:08

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

meow15:07:22

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

micha15:07:48

sooheon: you can do boot show -p

meow15:07:48

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

micha15:07:04

sooheon: and boot show -d

micha15:07:15

those two will show information about dependencies

sooheon15:07:07

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

sooheon15:07:46

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?

sooheon15:07:19

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

micha17:07:18

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

micha17:07:40

boot uses apache Aether

micha17:07:53

via pomegranate

micha17:07:15

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

micha17:07:30

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

micha17:07:50

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

micha17:07:18

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

micha17:07:42

basically it resolves transitive depdendencies as a pre-order traversal

sooheon17:07:45

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

micha17:07:52

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

micha17:07:42

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

sooheon17:07:03

Yeah depending on specific needs

micha17:07:10

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

micha17:07:37

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

sooheon17:07:38

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

micha17:07:38

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

micha17:07:25

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

micha17:07:42

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

micha17:07:48

so for example

micha17:07:14

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

micha17:07:39

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

micha17:07:01

now suppose you publish this project jar to maven

micha17:07:29

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

micha17:07:57

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

micha17:07:00

does that make sense?

sooheon17:07:27

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

micha17:07:53

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

sooheon17:07:54

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

sooheon17:07:09

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

micha17:07:11

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

micha17:07:51

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

micha17:07:14

the example they use is the servlet classes

micha17:07:51

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

micha17:07:09

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

micha17:07:22

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

micha17:07:53

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

micha17:07:19

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

micha17:07:33

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

sooheon17:07:37

I think I understand

sooheon17:07:52

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

sooheon17:07:03

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

micha17:07:09

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

micha17:07:18

you will see stack traces for those warnings

micha17:07:35

that will show you where those deprecated functions are being called

micha17:07:54

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

sooheon17:07:22

-vv is really cool

sooheon17:07:56

Ok one more

sooheon17:07:12

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)

sooheon17:07:33

I never specified this piggieback anywhere

micha17:07:39

ah, that's the cljs compiler

micha17:07:05

so the cljs compiler needs clojure 1.7.0

micha17:07:40

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

sooheon17:07:54

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

micha17:07:15

what does boot --version show?

sooheon17:07:34


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

sooheon17:07:40

I just ran boot -u though

micha17:07:46

you might need to do this

$ BOOT_CLOJURE_VERSION=1.7.0 boot -u

micha17:07:05

that will configure boot to use clojure 1.7

micha17:07:22

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

micha17:07:42

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

sooheon17:07:58

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

micha17:07:16

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

micha17:07:42

$ BOOT_CLOJURE_VERSION=1.7.0 boot -V > boot.properties

micha17:07:45

in the project dir

micha17:07:59

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

micha17:07:14

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

micha17:07:28

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

micha17:07:42

you can have the boot.properties file in source control

sooheon17:07:15

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

micha17:07:30

how do you mean?

sooheon17:07:37

With the source control

sooheon17:07:53

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

micha17:07:14

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

micha17:07:44

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

micha17:07:03

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

micha17:07:16

that could break your build, possibly

micha17:07:32

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

micha17:07:49

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

sooheon17:07:34

Boot is pretty freaking awesome

micha17:07:47

haha that's great to hear simple_smile

sooheon17:07:08

Thanks for your help, really appreciate it

sooheon17:07:28

I may have many many more dumb questions

micha17:07:30

np! it's my pleasure

sooheon18:07:23

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

micha18:07:58

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

sooheon18:07:30

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

micha18:07:56

you did BOOT_CLOJURE_VERSION=1.7.0 boot -u?

sooheon18:07:58

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

micha18:07:18

one sec i see if i can reproduce

sooheon18:07:31

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

sooheon18:07:48

very next boot -u will show 1.6.0

micha18:07:49

oh, that makes sense

micha18:07:59

boot -u is resetting the defaults

sooheon18:07:24

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

sooheon18:07:27

that’s causing this

micha18:07:37

well it's not having the environment variable set

micha18:07:55

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

micha18:07:12

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

sooheon18:07:39

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

sooheon18:07:23

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

sooheon18:07:37

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

sooheon18:07:58

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

micha18:07:15

dependency issues are a pain in the butt

meow19:07:52

@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"]

meow19:07:40

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

meow22:07:11

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

meow22:07:58

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