Fork me on GitHub
#boot
<
2015-12-16
>
flyboarder00:12:50

@micha: is the 2.5.0-SNAPSHOT supposed to work from boot.properties?

micha00:12:13

no i had some issues with clojars

micha00:12:21

working on it now tho

micha00:12:35

i corrupted one of the files in the maven repo by trying to deploy from my home connection which is super slow

flyboarder00:12:23

hahaha oh man, well these things happen πŸ˜›

flyboarder00:12:52

ill wait until tomorrow to test it out

micha01:12:48

@flyboarder: ok i think we're in business

micha01:12:14

you can set BOOT_VERSION=2.5.0-SNAPSHOT in your ~/.boot/boot.properties file

micha01:12:24

and it should download everything and update itself

donmullen02:12:51

Nice : Boot @ 36:26 : https://www.youtube.com/watch?v=50vU6rp2jyA (Interactive programming - Daniel Szmulewicz)

flyboarder05:12:26

@micha: still not working

flyboarder05:12:40

i think there is a space in the url it is trying to resolve

micha05:12:12

did you put a space in the boot.properties file? simple_smile

micha05:12:13

that's a bug!

micha05:12:33

it should trim the values from the properties file

micha05:12:10

i guess that gets tricky

micha05:12:41

probably don't want to change the properties file semantic

flyboarder05:12:38

are you managing the properties yourself or with propertied?

micha05:12:54

what is propertied?

micha05:12:12

oh, that stuff happens in the java part of boot

flyboarder05:12:11

I know basically no java so I can only kinda read that πŸ˜›

flyboarder05:12:28

shouldnt each property be passed to something that checks it’s of the expected format?

flyboarder05:12:19

like they are all strings really but this might also be good for the settings which are paths

micha05:12:07

yeah some validation could be done

flyboarder05:12:54

@micha: now I know this is a task error but not sure if it means a bug in the option validation that was changed

flyboarder05:12:02

cli: option notifier: expected optarg, got sym

micha05:12:55

can you paste the task definition please?

micha05:12:18

that looks like a legit error

flyboarder05:12:11

im just calling notify

micha05:12:40

yep that's a bug

micha05:12:00

so the --notifier option needs an optarg

micha05:12:15

i don't think that ever worked

micha05:12:41

same with the rest of the options, --title, --icon, --pid

micha05:12:09

try using those options from the command line with 2.4.2

micha05:12:18

they won't work

micha05:12:33

line 47 is ok

micha05:12:40

the rest are not

flyboarder05:12:44

hm but it works in 2.4.2 boot file?

micha05:12:02

try giving the --title option on the command line

micha05:12:13

with boot 2.4.2

micha05:12:18

does it work?

micha05:12:35

BOOT_VERSION=2.4.2 boot notify --title foobar

flyboarder05:12:08

so that fails also

micha05:12:22

so the new error things are working simple_smile

flyboarder05:12:27

so the new validation is correct then?

micha05:12:28

finding bugs, fixing them

flyboarder05:12:42

yeah ok ill open an issue on the notifyer task

flyboarder06:12:13

@micha: im still having the issue where .hl files in a checkout dep are not recompiled

flyboarder06:12:44

everything else looks good tho! especially the new target task!

micha06:12:48

oh yeah, it might be overly aggressive caching in boot-hoplon?

micha06:12:05

awesome! thanks for testing it out

micha06:12:44

are you on windows btw?

flyboarder06:12:05

i havnt tested it on my windows builds yet

flyboarder06:12:13

but yes i use boot for windows automation

micha06:12:35

okay cool, hopefully it will work smoothly there too

flyboarder06:12:21

is there a boot wish list somewhere? i’d really love to help working on clr support

flyboarder06:12:42

my dream is clojure (boot) on windows without java

micha06:12:01

that would be awesome yes

micha06:12:08

a wiki page perhaps?

micha06:12:33

the groundwork i think has been laid, becaue boot does work with dunaj, which is an alternative to clojure

micha06:12:19

i guess that's not really helpful

micha06:12:28

because dunaj runs on the jvm so interop works

micha06:12:40

we'd need to abstract away the interop parts

micha06:12:49

which is good practice anyway

flyboarder06:12:21

yeah i can help with some of the c# interop but I think refactoring the codebase just to abstract the current logic would be the first step instead of trying to do both

micha06:12:47

there is a lot of interop in boot for performance

micha06:12:22

but it's all wrapped in clojure so it's doable

flyboarder06:12:58

mhm im trying to get through all the java, maybe making boot build with boot will be my next challenge, the multi thing looks promising with the target task now

flyboarder06:12:22

but first real work πŸ˜›

micha06:12:50

there is a branch curently that almost works

micha06:12:54

with boot building boot

micha06:12:10

the problem is that we use AOT (again, perf)

micha06:12:34

so the classes that are loaded in boot already can't be compiled, because they're already loaded

micha06:12:44

so we'd need to defer compilation or just forgo AOT

micha06:12:14

one possible solution would be to have boot compile itself at runtime and cache the class files

micha06:12:28

like the first time you run boot it compiles its own classes

flyboarder06:12:38

and thats kinda what I was thinking for the cross platform

flyboarder06:12:53

first run compiles platform classes

micha06:12:59

yeah it could choose the implementation based on the platform

micha06:12:44

that would be good also for binary compatibility, like you could compile for your version of the clr or jvm

micha06:12:28

that might give some optimization possibilities with newer versions of the platform maybe

micha06:12:48

currently i compile on java 1.7 for binary compatibility

micha06:12:07

the compiled classes will still work on 1.8 and 1.9

flyboarder06:12:08

mhm and allows for wider version testing

micha16:12:58

boot version 2.5.0 has been released

micha16:12:07

boot -u to try it out

thomas16:12:28

@micha: and all the others thank you for working on this.

jannis16:12:30

Hi! I'm wondering if I am hitting a boot bug here. My project depends on [circleci/clj-yaml "0.5.5"] and boot builds it into my uberjar - however, it also builds in a different clj-yaml project that my project depended on before. And that last one ends up being used.

jannis16:12:42

As far as I'm aware none of the other dependencies provide the other clj-yaml dependency. But I can't be certain. Is there a way to find out?

micha16:12:05

@jannis: can you do boot show -p and look for clj-yaml please?

micha16:12:46

that will show you why the selected version was selected

micha16:12:57

and what other dependencies are trying to bring in other versions

jannis16:12:56

I just wiped the cache etc. and running boot show (not finished) is downloading a clj-yaml-0.4.0.jar, which I think is the thing I depended on before. So it must be used by one of the current dependencies.

micha16:12:16

yeah the cache shouldn't need to be deleted, but it also doesn't hurt

micha16:12:31

i think the other clj-yaml is with a different group id, right?

micha16:12:59

like just [clj-yaml "1.2.3"] vs [circleci/clj-yaml "4.5.6"]

micha16:12:17

those are two completely different artifacts

micha16:12:24

so one won't preclude the other

micha16:12:59

you will want to add an :exclusions [clj-yaml] to the dependency that is pulling in clj-yaml

micha16:12:16

but that might also make that thing broken

micha16:12:25

so you might want to have both in your uberjar

micha16:12:44

is there any reason why you don't want to just have both in there?

jannis16:12:23

Because they both use the same clojure namespace (`clj-yaml.core`) (one is a maintained fork of the other) but have incompatible function signatures.

jannis16:12:27

I see no other clj-yaml in there other than circle/clj-yaml.

micha16:12:27

that's quite the faux pas

micha16:12:37

pro tip: don't do that

jannis16:12:58

Of course. I didn't do it simple_smile

micha16:12:07

lol i know, just sayin

micha16:12:24

now you're in dependency hell

jannis16:12:25

Even org.clojure/clojure itself did depend on circleci/clj-yaml in 1.6.0, but... yeah.

micha16:12:47

clojure has dependencies?

micha16:12:51

i did not know that

jannis16:12:42

I guess so?

[:heavy_check_mark:] org.clojure/clojure
    ✘ 1.7.0-RC1
      weasel
    :heavy_check_mark: 1.7.0
      com.novemberain/pantomime
      com.stuartsierra/component
      org.clojure/clojure
      org.clojure/clojurescript

micha16:12:13

oh, no that's kind of inverted

micha16:12:30

the top level thing is the artifact that's in your project

jannis16:12:31

I was just wondering why it shows up under itself πŸ˜‰

micha16:12:42

so your project will have clojure

micha16:12:03

the lower level things are the dependencies in your build.boot that want to puill in different versions of the top level thing

micha16:12:25

you can see there that weasel wants to pull 1.7.0-RC1 into your project

micha16:12:45

but you can also see the checked one, which indicates the version that was actually chosen

micha16:12:03

and you can see it was chosen because you specified a version of clojure in your build.boot

micha16:12:15

but also other deps in your build.boot wanted to pull in that same version

jannis16:12:22

I don't see a checked circleci/clj-yaml though, so are all of these indirect/provided dependencies?

micha16:12:22

like component and clojurescript

micha16:12:43

the top level things are only contested dependencies

micha16:12:52

if there is no conflict then they won't show up there

micha17:12:05

boot show -d will show the deps tree

micha17:12:21

that reflects the dep graph that was actually chosen

micha17:12:29

but not all the other possible graphs

micha17:12:39

the other possible graphs are shown in boot show -p

micha17:12:13

so cljs-yaml will show up in boot show -d, but not in boot show -p unless it's a contested version

micha17:12:30

so in the thing you pasted above

micha17:12:40

suppose for some reason you wanted to use 1.7.0-RC1

micha17:12:48

you would look at the show -p output

micha17:12:19

and add :exclusions [org.clojure/clojure] to the deps under the second level heavy check mark

micha17:12:25

eg clojurescript, etc

micha17:12:48

that's not a great example because you directly specified clojure in your build.boot deps

micha17:12:53

but you get the idea

micha17:12:39

there is also a global :exclusions key you can use in the boot env

micha17:12:56

that will apply it to all your deps

jannis17:12:53

boot show -p shows that ring-middleware-format uses the old clj-yaml, hence the conflict.

micha17:12:32

yeah you're in a pickle really

jannis17:12:39

Since I need that depedendency and the two clj-yaml projects occupy the same namespace... is there a way to solve this?

micha17:12:50

well pods

micha17:12:56

that's what pods are for

jannis17:12:07

Well, I could send a pull request to ring-middleware-format...

micha17:12:21

but this forking practice is a virus

micha17:12:39

i can't believe they'd do that

micha17:12:57

they basically checkmated you

jannis17:12:42

I guess there is another way... roll my own fork as a different namespace in my project.

jannis17:12:51

Awesome, right? simple_smile

micha17:12:55

yeah that's what i'd do

micha17:12:17

fork the circleci one and rename the namepsaces or whatever

juhoteperi17:12:27

R-m-f should use latest clj-yaml already

jannis17:12:06

@juhoteperi: Oh, the r-m-f version I use is outdated.

jannis17:12:15

You're right, they use circleci's now.

jannis17:12:29

So there we go...

jannis17:12:37

The solution was right there

jannis17:12:05

@juhoteperi: Thanks for pointing it out.

jannis17:12:27

@micha: And thank you for explaining things. I do know boot show now, which is cool.

jannis17:12:15

...and it works! simple_smile

juhoteperi17:12:00

@micha: Maybe develop branch for next version and master for fixes to current version?

micha17:12:13

yeah that's what i was thinking, too

micha17:12:24

the patch releases could be via pr to master

juhoteperi17:12:38

And new features to develop

micha17:12:59

and we rebase 2.6.0-SNAPSHOT on master and force push

micha17:12:09

like when we merge a pr to master

micha17:12:16

is that a problem for you?

juhoteperi17:12:24

I think just merge would be better

micha17:12:26

it would ust mean delete branch and re-pull

juhoteperi17:12:43

rebase and force push should only be used for personal branches

juhoteperi17:12:50

and development branch is not such

micha17:12:20

maybe make a new branch after each rebase

micha17:12:32

like 2.6.0-SNAPSHOT-0

micha17:12:38

i think that works in maven

juhoteperi17:12:45

I would prefer just git flow workflow

juhoteperi17:12:55

master and develop branch and merge between them as needed

micha17:12:57

i'd like to be able to rearrange commits if possible

micha17:12:11

so we can keep optimal git bisect behavior

micha17:12:22

and if we need to revert a feature we can do it cleanly

micha17:12:06

the only problem with the git flow is with bisect and revert

micha17:12:19

because features are spread across merges and whatnot

juhoteperi17:12:35

Do we even need separate master and development branches?

micha17:12:52

i made the dev branch for the rebasing

micha17:12:56

but i'm not married to it

juhoteperi17:12:22

Personal branches are ok for rebasing, but if we start to merge PR's to a branch which is rebased, things start to break easily

micha17:12:40

yeah i agree there

micha17:12:05

no rebasing

juhoteperi17:12:11

Maybe we just keep merging PRs to master and create branches as needed

micha17:12:21

yeah that is probably the best option

micha17:12:37

and we can just deal with reverts and bisects

juhoteperi17:12:56

Separate develop branch is only useful if we wanted to release bug fixes without releasing some new features

juhoteperi17:12:09

But that's not too useful, we can just release bug fixes with next feature release

micha17:12:41

yeah or make topic branches if we want to make a limited release to see if a feature is good or not

micha17:12:04

it would be nice to get feedback about new features somehow

micha17:12:12

before releasing them

micha17:12:41

it would have been nice to have snapshot deployed earlier this time, maybe

micha17:12:48

so people could be using it

danielsz17:12:55

What does this mean? Implicit target dir is deprecated, please use the target task instead.

danielsz17:12:17

Just updated to boot 2.50

micha17:12:34

in the future boot won't automatically write to the target directory

micha17:12:47

there is now a task for that, target

danielsz18:12:42

what will happen if you don't use the target task? Where do the compiled artefacts go?

danielsz18:12:37

non capiche

micha18:12:57

a lot of times you don't care about the target

micha18:12:33

or the target introduces some issues, like if you run two instances of boot

danielsz18:12:49

OK, I'm trying to wrap my head around the implications

danielsz18:12:24

This will require a target task to be injected?

micha18:12:04

yeah if you want the fileset to be dumped into a directory you'd want to use the target task

juhoteperi18:12:24

Will the target task clear the target dir?

micha18:12:30

(comp
  ...
  (target :dir ["target]))

juhoteperi18:12:38

Would be useful to have a task which copies a single file to given target

micha18:12:50

yes, we may want to make that an option though, to disable clearing

micha18:12:16

the sift task is really fast now

juhoteperi18:12:26

Yeah I'll probably use sift to select only the uberjar anyway

danielsz18:12:30

with boot 2.5.0, I am seeing this: Caused by: java.lang.ClassNotFoundException: clojure.core.reducers.CollFold

micha18:12:02

there was a ticket about this

micha18:12:42

@danielsz: can you paste stack trace please?

danielsz18:12:48

micha, how can I quickly revert to boot 2.4.2 on my production server. Emergency here.

juhoteperi18:12:01

@danielsz: Just edit ~/.boot/boot.properties or set BOOT_VERSION=2.4.2 on shell

juhoteperi18:12:21

or maybe it's ~/.boot/cache/boot.properties nowdays

danielsz18:12:28

@micha: OK, I'm back to safety on the production server. Now I can look at what happened with boot 2.5.0.

danielsz18:12:08

@micha: Looks like it's an aot thing. It only happens when I run the uberjar.

micha18:12:38

@danielsz: if you can make a repo that demonstrates i can investigate

danielsz18:12:10

@micha: I'm continuing the investigation. will update.

alandipert18:12:14

@danielsz: i get that error when i try to resolve CollFold without requiring cloujre.core.reducers

alandipert18:12:34

perhaps boot versions prior worked because we required reducers somewhere? and your code didn't have to

micha18:12:34

yeah that's what #258 was about i think

danielsz18:12:39

@alandipert: could be. But then it comes from a third party library. I don't use reducers.

danielsz18:12:56

I've updated the cider-nrepl. Could be the middleware.

alandipert18:12:32

thanks! and thank you for your work on the changelog

alandipert18:12:25

good catch! fixed

danielsz18:12:30

@alandipert: @micha Awesome notes for the new release. Congrats! 🍻

alandipert19:12:11

@danielsz: thanks! to you to. thanks for all your help

danielsz19:12:04

@micha: @alandipert I think the problem was elsewhere. With boot 2.5.0, the build task produces project.jar while before it was producing an artefact named after the project pom. https://www.refheap.com/112766

danielsz19:12:21

God, I hate to be the messenger of bad news at a time like this.

danielsz19:12:03

I could be missing an important piece, too.

danielsz19:12:38

The target task makes sense. I understand the motivation after having read the notes.

danielsz19:12:45

The pom task has been extended, but no API breakage. Is order of importance in the build pipeline (https://www.refheap.com/112766 ) that could explain my observation?

danielsz19:12:36

It looks like the pom's project name is not being carried over by the uber or jar task.

asolovyov19:12:51

hey guys! Any ideas what can cause errors like this after upgrading to boot 2.5? http://paste.in.ua/1097/

danielsz20:12:25

@micha: This tripped me up: Jar task produces jar with default name (project.jar) when multiple poms are found in the jar and the --file option isn't given.

danielsz20:12:58

@micha I have only one pom, but the jar produced is project.jar

danielsz20:12:59

@micha: By specifying the filename with -file on the jar task I could get the expected pom project name back.

micha20:12:20

@danielsz: you're making an uberjar right?

micha20:12:40

can you please do this:

micha20:12:58

jar tf target/project.jar |grep pom.xml

micha21:12:08

where target/project.jar is your uberjar

micha21:12:17

to verify that there is only one pom in there

danielsz21:12:59

Sure. So there are plenty of poms there.

danielsz21:12:17

But these are the poms of dependencies

micha21:12:31

that was another bugfix

micha21:12:40

we were removing those by default before

micha21:12:58

but that interferes with libraries that look for their own pom to know what version they are

danielsz21:12:20

ah, I understand

danielsz21:12:29

No easy fix then, I guess.

danielsz21:12:39

Not a big problem anyway, but a surprise.

micha21:12:32

maybe changing the default jar exclusions was a bad decision

danielsz21:12:29

Another thing I was wondering about: is there a use case for writing the fileset to multiple directories at once, since the :dir option is a set?

danielsz21:12:16

(in the target task)

micha21:12:46

probably not

danielsz21:12:49

@micha: i might have to rewrite boot-runit against boot 2.5.0. In particular, the logic that was extracting information from the pom. It was selecting the first pom, since others were excluded. This logic is now broken if I understand correctly.

danielsz22:12:00

@micha: and @alandipert I could confirm that the change in jar exclusions breaks boot-runit. I can't just scan the fileset for a pom.xml and presume it belongs to the project. When building an uberjar, fileset is full of pom.xmls from dependencies.

danielsz22:12:24

I can add an option to boot-runit to provide the name of the uberjar, and get rid of the guessing.

danielsz22:12:30

Is this what we want?

micha22:12:53

you could sift out the poms when you make the uberjar

micha22:12:27

sift --exclude 'pom.xml$'

micha22:12:43

if you do that before your pom task in the pipeline you won't get any deps poms

micha22:12:59

before your pom task but after uber of course

micha22:12:30

the real problem here is that there is no convention for application descriptor files

micha22:12:47

like artifacts in maven have a pom.xml that provides metadata

micha22:12:14

but i don't know of any equivalent thing for applications, which is what your uberjar is

micha22:12:46

perhaps the manifest.mf file

micha22:12:52

there you go

micha22:12:01

add metadata to the jar manifest

micha22:12:10

then your runit task can look at that