Fork me on GitHub
#boot
<
2016-05-13
>
kenny00:05:29

Also what is the directory structure for the template supposed to be? Does it mirror yours: src/boot/new/<template>/<template files>

kenny01:05:46

Figured it out 🙂

seancorfield01:05:11

@kenny: Cool. Sorry, was off wrestling with PostgreSQL and java.jdbc and Docker.

seancorfield02:05:53

Here’s one of my Boot templates if you want to compare notes: https://github.com/framework-one/fw1-template

malcolmsparks11:05:31

hi - I see that boot checkout is marked in the code as DEPRECATED - is there a replacement? What's the best approach to incubating a library in another project?

mccraigmccraig11:05:15

@malcolmsparks: don't know if there is a better solution, but i've just added something like "checkouts/incubating-lib/src" to :source-paths in build.boot, which seems to work fine for simple cases (i.e. no resources to worry about)

malcolmsparks11:05:29

@mccraigmccraig: cool, that sounds obvious and simple - just what I was looking for!

malcolmsparks11:05:58

of course the problem is if you have transitive dependencies (I don't at this stage)

martinklepsch11:05:01

@malcolmsparks: @mccraigmccraig note that this only works if you have all dependencies covered already

malcolmsparks11:05:57

oh - so the checkout task is now in boot core?

malcolmsparks11:05:27

my boot -u isn't working - I'm stuck on 2.5.5 😞

slotkenov11:05:03

I can’t seem to connect to the cljs-repl from vim-fireplace by executing :Piggieback (adzerk.boot-cljs-repl/repl-env)

slotkenov11:05:21

Vim freezes forever. I need to stop it with Ctrl-c

malcolmsparks11:05:31

ah, so boot 2.6.0 hasn't been released yet

juhoteperi11:05:07

@slotkenov: Do you have the page open in a browser?

juhoteperi11:05:28

Piggieback wait until a browser connects to the repl server

juhoteperi11:05:33

s/wait/waits/

slotkenov11:05:57

@juhoteperi: at the moment not connected

juhoteperi11:05:09

If you have the app open in a browser, it should automatically connect to browser repl server when you run the Piggieback command on Vim. But if it doesn't, you can try reloading the app.

slotkenov11:05:33

even reloading the browser doesn’t stop vim from from being frozen

slotkenov11:05:50

@juhoteperi: to check if I understand the whole process: in terminal A I start my boot development task which also runs cljs-repl then in terminal B I run boot repl -c and then in that repl I run (start-repl) to start the ClojureScript repl and then I reload the page to connect it with the repl after that I try running Piggieback from vim

juhoteperi11:05:26

You either run (start-repl) OR run Piggieback from Vim, not both. They do the same thing.

martinklepsch11:05:33

@malcolmsparks: I'd just stick with the checkout task for now, I'm sure once there is a release migration will be easy 🙂

slotkenov12:05:24

@juhoteperi, yeah that works, can’t seem to get fireplace to work properly though

slotkenov12:05:28

It works from a .clj file, but not from a .cljs file

malcolmsparks12:05:57

I hope that 2016 will be the year we can say goodbye to the pointless practice of fiddling with version strings in source code every time we release - a Maven legacy we can well do without, good riddance to it

malcolmsparks12:05:37

@seancorfield: would dearly love to see something like this in boot new, any thoughts?

martinklepsch12:05:41

@malcolmsparks: I recently thought a resources/com/project/project.edn might be all that's needed. can be read at run and build time..

malcolmsparks12:05:25

@martinklepsch: would project.edn have the version hardcoded in it? For me, this practice leads to so much noise in git histories and it also works against the discipline of tagging your library releases

martinklepsch13:05:59

@malcolmsparks: it would. With a git-tag-only approach how would you make the version available at runtime?

malcolmsparks13:05:58

@martinklepsch: Depending on what your runtime was built on (jar, uberjar, rpm, boot run, etc..) you could either burn it into the pom, jar, etc. or set it as a System property, etc.

malcolmsparks13:05:10

the point is that having both git and Maven fight over the version is an area of unnecessary pain

martinklepsch13:05:29

@malcolmsparks: ok, so essentially generate something like VERSION.properties at build time, y?

malcolmsparks13:05:24

yes, I'm only arguing about the original golden source of the version itself - it's fine to derive artefacts from it such as a VERSION.properties

martinklepsch13:05:50

yeah, got it 🙂 tbh I've never used git tagging/proper release cycling much so I'd totally appreciate some tooling making that more fluid 👍

malcolmsparks13:05:28

unfortunately lein missed the opportunity to sort this mess out once and for all, now we're stuck with it. But with boot we have a limited window again to fix it

malcolmsparks13:05:02

there are so many projects now that don't tag properly, or consistently, let alone sign those tags - and the commit histories for most projects look like: fix typo, release new version, upgrade version number, fix bug, release new version, upgrade version number, fix typo etc... which is all unnecessary noise

richiardiandrea15:05:05

boot-semver gives you version.properties, adding git tag synchronization there would be great indeed

ajchemist15:05:56

Hi, I’ve just wondered if boot can make standalone uberjar?, like lein uberjar. and use it just single command java -jar.

martinklepsch15:05:09

@ajchemist: there's an uber task: boot uber -h

martinklepsch15:05:38

essentially boot pom uber jar would make an uberjar

ajchemist15:05:12

thx guys, but It seems boot pom uber jar emit jar file that its contents are exploded. so the jar size is somewhat huge.

martinklepsch15:05:07

@ajchemist: that's the point of an uberjar. by using an uberjar you avoid downloading dependencies later on by just putting them in your artifact

ajchemist15:05:09

hmm, ok. I mean exploding all jar’s contents.

ajchemist15:05:56

so I tried uber task’s as-jars options, then I can't excute the jar file with java -jar.

ajchemist15:05:06

oh my bad. there’s some misunderstanding about as-jars options. oops

donmullen15:05:59

@alandipert: re: #C08BDAPRA aws deploy question - best here — are you all moving away from https://github.com/adzerk-oss/boot-beanstalk ?

donmullen15:05:29

And beanstalk in general.

seancorfield16:05:25

https://clojurians.slack.com/archives/boot/p1463142817002334 Sounds like a generator for Boot or an extension to boot-semver would be a great Pull Request?

seancorfield16:05:28

I think the reason we haven’t seen a solid solution to this (and lein release is a bit of a complex mess) is that there are lots of different ways to manage projects and lots of different requirements from different people.

seancorfield16:05:18

At World Singles, we’ve moved to a shared .properties file for common "pinned" versions for libraries and an EDN file for each project to specify its dependencies. It would be a small step for us to add the project version to the EDN file and then bake that into our JARs etc.

seancorfield16:05:42

But I don’t think our approach would work for everyone — I think it would be far too opinionated for a lot of people.

richiardiandrea16:05:30

the version.properties file for me works well because it addresses a single "principle"/"responsability", it is a single source of truth for versioning...I merge it with my system/config as a separate step and it ends up in greeting when the app starts https://github.com/Lambda-X/lambone/blob/master/resources/leiningen/new/lambone/common/src/backend/system.clj#L29

malcolmsparks17:05:50

@seancorfield: thanks for your comments. The design I'm thinking over would be one where a project elects to source the version from the git tag rather than specifying it in a file. My code snippets offer up an approach based on git describe which sets the version to the current git tag unless there has been subsequent commits or the working tree is dirty, in which case the version is set to the next number + SNAPSHOT. Therefore, for these projects, git becomes the sole authority of the version, in effect forcing adopters to control project version using git tags.

malcolmsparks17:05:35

My appeal to the group is that now we are beginning to use boot for library publication, please keep boot agnostic to how the version is determined. The approach taken by Maven and inherited by Leiningen has been detrimental to consistent reliable versioning, cluttered git histories and led to sloppy practices which I feel we need to improve on.

malcolmsparks17:05:36

As a practical step, a version derivation function could be baked into standard boot new templates. Better still, baked into boot core. Just want to gauge the group's appetite for this. You're right that there are strong divergent opinions on this topic.

micha18:05:19

@malcolmsparks: you are not suggesting a change to artifacts in maven right? like the pom.xml is still the same etc., and dependencies are still specified as maven coordinates, right?

mobileink18:05:23

@malcolmsparks: agreed. version (and build) strings should be provided by a service rather than hardcoded somewhere. but you’d want to make it pluggable so as not to restrict it to git. a clojure protocol rather than a boot task?

micha18:05:15

this is just the mechanism to set the version of the library you're building, right?

mobileink18:05:23

on the other hand, i’m not sure we want the maven version string to always be set by a git tag. sometimes you want git tags for reasons other than versioning.

mobileink18:05:02

you’d want some way to say “use this tag for maven versioning”, which I guess could be done by convention, e.g. “MVN-0.2.2-SNAPSHOT” or sth

malcolmsparks18:05:52

@micha Exactly. pom.xml files are generated- anything you wouldn't normally add to a git repo just stays the same. My concern is with the requirement to /change/ your git repo once you decide you're ready to release it.

micha18:05:05

i like that 👍

malcolmsparks18:05:48

@mobileink: yes, you have a very valid point. My snippets today ignore tags that aren't satisfied by a regex.

micha18:05:49

i already have the +version+ var that i set manually and is used to configure other things

micha18:05:04

seems like it would be better for that to be deduced automatically from git

micha18:05:00

this would also simplify making tasks like npm version in boot

micha18:05:16

like boot version -t patch

micha18:05:44

to increment the version in git etc

micha18:05:08

also i think the regex discriminator would totally work for me

micha18:05:46

like /^[0-9]+\.[0-9]+\.[0-9]+$/, i'd never make a tag like that other than for a release

malcolmsparks18:05:12

@micha Yes. I'm suggesting that your source code remains constant. So something like (def +version+ (boot.git/derive version-from-tag #"[0-9.]+") should be an option

micha18:05:25

awesome, i like it

malcolmsparks18:05:44

Missing hyphen between derive and version, sorry on smartphonr

micha18:05:06

i think the pom task could work in a slightly different way to make this more smooth

micha18:05:31

the pom task could merge properties into an existing pom.xml if one is present in the fileset

micha18:05:45

instead of ignoring an existing pom and overwriting it

micha18:05:00

then you could set the version in a completely separate operation

micha18:05:11

and all the things that need the version will get it from the pom anyway

micha18:05:41

so you could call the pom task multiple times

micha18:05:45

in a single pipeline

micha18:05:51

things like that

mobileink18:05:13

I think you need more than just the number, you need to select a tag type, e.g. MVN, to avoid conflicts.

micha18:05:49

what could it conflict with?

micha18:05:33

i can't see myself making a tag like 1.2.3 unless it's to tag a release

mobileink18:05:55

another use case: appengine requires an app version string with a constrained syntax that does not accept mvn version strings. app version and source version may vary independently.

micha18:05:17

app versions are a separate concern i think

micha18:05:35

like applications won't be dependencies, so the requirements there are far less rigorous

micha18:05:50

you don't need to coordinate with others, basically

mobileink18:05:59

yes but at least in some cases I'd like to drive them from version control. maybe. I think. ;)

micha18:05:33

but i mean it would still work, because your app isn't going to be a maven dependency

micha18:05:49

like you won't have a pom.xml file

micha18:05:15

so the "version" is not conflicting with maven

micha18:05:20

because maven isn't in the picture

mobileink18:05:18

yes, I'm thinking beyond maven, on the general principle that version stuff is meta and should not be hard coded internally. but I have to think about it some more.

alandipert18:05:58

the app/lib distinction is another thing lost on most tools, that leads to lots of unneccesary typing imo

alandipert18:05:06

like the idea that your defproject needs a version even if it's an application

malcolmsparks18:05:52

@mobileink: I believe my snippet above addresses the use-case where you want to provide the version regex explicitly: (def +version+ (boot.git/derive-version-from-tag #"[0-9.]+"))

malcolmsparks18:05:35

But a default of (def +version+ (boot.git/derive-version-from-tag)) could be provided via another fn form

malcolmsparks18:05:55

@alandipert: totally agree - I have some client projects that have been on 0.0.1-SNAPSHOT forever simply because they aren't released as libraries and we don't bother using the lein version

mobileink18:05:57

what if I have some tag that matches but is not intended as an mvn version tag? I may be misunderstanding.

malcolmsparks18:05:59

@mobileink: that's why I'm sort-of proposing you could provide a regex that would match only your mvn version tags

malcolmsparks18:05:31

but actually I agree with @micha this is a corner-case - mostly a tag like 1.2.8 is pretty obviously a version

malcolmsparks18:05:11

but boot is so flexible - this conversation is kind of academic because boot right now is agnostic (which I like)

micha18:05:39

i don't see any reason to ever make it less agnostic there

micha18:05:48

definitely won't hardcode in anything

malcolmsparks18:05:59

exactly, but providing some idioms might be a nice move - but really what I've been saying today is 'well done' to boot for not falling down this trap of forcing users to specify the version in source code control (which leads to the chicken-and-egg problem that Lein and Maven face)

malcolmsparks18:05:52

it's no secret my company juxt are rooting for boot to succeed and (slowly) migrating many of our client projects over to it

mobileink18:05:17

@malcolmsparks: d'oh! I was misreading the code, sorry.

malcolmsparks18:05:58

agnotic is good 🙂

malcolmsparks18:05:10

(better when spelled correctly)

mobileink18:05:29

I think the solution here would work nicely even where multiple version "types" are involved. just settle on a convention for tag syntax and select them with a regex. I like it.

richiardiandrea18:05:05

When I do boot watch notify test I quickly get Exception in thread "Thread-37" java.lang.OutOfMemoryError: Metaspace

richiardiandrea18:05:20

version 2.6.0-SNAPSHOT

richiardiandrea18:05:50

I naively set: -XX:MaxMetaspaceSize=1g

richiardiandrea18:05:13

I am in dev but it's a bit big 😄

micha18:05:33

@alandipert posted this link in the adzerk slack yesterday, might be useful for that exception: https://stuartsierra.com/2015/05/27/clojure-uncaught-exceptions

mobileink19:05:37

@micha: to you question "why?" : because I misunderstood, oops.

mobileink19:05:44

pod question here. --checkout is working fine, but when a change is detected I need to re-explode or copy to target/foo, since appengine will not put anything outside of target/ on the classpath. but once --checkout works it magic I can no longer get at the original jar. so I use a pod. that works, but it means a new pod every time I change the source. is there a better way? can I keep the same pod hanging around and just run it on demand?

micha19:05:37

the original jar?

micha19:05:48

like the one the checkouts is using as its source?

mobileink19:05:11

yes. more specifically, with --checkout, resolve-dependency-jar fails. I guess because it's already on the cp in exploded form. tried for a while but could not figure out how to get at it except by pod.

mobileink19:05:17

a copy of the exploded jar would work but I couldn't figure out how to do that.

micha19:05:05

hmm i one sec let me look at the uber task implementation again, it has the answer you need

micha19:05:18

i need to document this before 2.6.0 fully

mobileink19:05:14

fyi I did meet around with uber. problem is I need to extract the jar deps to one place, and everything else to somewhere else. so I use uber --as-jars to place the jars (one time only) and then my custom task to get the stuff that could be edited. if that makes sense.

micha19:05:39

that gets the jar files that the checkouts are exploded from

micha19:05:52

co-jars are the jar files for the checkouts

micha19:05:16

the checkouts info is in the boot env

micha19:05:21

under the :checkouts key

micha19:05:31

so you have access to it via boot.pod/env as well

micha19:05:36

like in a pod

mobileink19:05:57

aha! yes, somebod needs to docs. ;) maybe me if I can get this working when I get back to the fortress of somnitude.

micha19:05:41

ah i was wrong above, the :checkouts key is just the deps you set with --checkouts option of course

micha19:05:47

or via set-env!

micha19:05:05

the get-checkouts function shows how to map the checkout deps to their jars

mobileink19:05:19

more generally: we do --checkout, and then a change is observed. does boot then run the whole pipeline from scratch, in another pod, or ? just curious.

micha19:05:35

yeah it acts the same as if a file in your project changed

micha19:05:50

basically the checkout jars are exploded into a hidden source-paths