This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (17)
- # aleph (1)
- # arachne (2)
- # boot (152)
- # braveandtrue (8)
- # cljs-dev (12)
- # cljsjs (3)
- # cljsrn (1)
- # clojure (105)
- # clojure-austin (1)
- # clojure-belgium (5)
- # clojure-berlin (1)
- # clojure-brasil (5)
- # clojure-canada (2)
- # clojure-dev (6)
- # clojure-gamedev (1)
- # clojure-greece (9)
- # clojure-russia (39)
- # clojure-uk (9)
- # clojurescript (106)
- # component (4)
- # cursive (1)
- # data-science (3)
- # datascript (1)
- # datomic (9)
- # emacs (6)
- # hoplon (92)
- # jobs (1)
- # ldnproclodo (2)
- # lein-figwheel (1)
- # off-topic (19)
- # om (47)
- # om-next (1)
- # onyx (10)
- # other-languages (1)
- # proton (1)
- # re-frame (5)
- # reagent (36)
- # rethinkdb (1)
- # ring (2)
- # rum (1)
- # yada (14)
Also what is the directory structure for the template supposed to be? Does it mirror yours:
@kenny: Cool. Sorry, was off wrestling with PostgreSQL and java.jdbc and Docker.
Here’s one of my Boot templates if you want to compare notes: https://github.com/framework-one/fw1-template
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?
@malcolmsparks: don't know if there is a better solution, but i've just added something like
build.boot, which seems to work fine for simple cases (i.e. no resources to worry about)
@mccraigmccraig: cool, that sounds obvious and simple - just what I was looking for!
of course the problem is if you have transitive dependencies (I don't at this stage)
I can’t seem to connect to the cljs-repl from vim-fireplace by executing
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.
@juhoteperi: to check if I understand the whole process:
in terminal A I start my boot development task which also runs
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
You either run (start-repl) OR run Piggieback from Vim, not both. They do the same thing.
@malcolmsparks: I'd just stick with the checkout task for now, I'm sure once there is a release migration will be easy 🙂
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
@seancorfield: would dearly love to see something like this in
boot new, any thoughts?
@malcolmsparks: I recently thought a
resources/com/project/project.edn might be all that's needed. can be read at run and build time..
@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
@malcolmsparks: it would. With a git-tag-only approach how would you make the version available at runtime?
@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.
the point is that having both git and Maven fight over the version is an area of unnecessary pain
@malcolmsparks: ok, so essentially generate something like
VERSION.properties at build time, y?
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
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 👍
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
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
boot-semver gives you
version.properties, adding git tag synchronization there would be great indeed
Hi, I’ve just wondered if boot can make standalone uberjar?, like
lein uberjar. and use it just single command
https://github.com/adzerk-oss/boot-uberjar-example might be helpful reference
thx guys, but It seems
boot pom uber jar emit jar file that its contents are exploded. so the jar size is somewhat huge.
@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
so I tried uber task’s
as-jars options, then I can't excute the jar file with
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?
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.
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.
But I don’t think our approach would work for everyone — I think it would be far too opinionated for a lot of people.
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
@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.
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.
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.
@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?
@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?
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.
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
@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.
@mobileink: yes, you have a very valid point. My snippets today ignore tags that aren't satisfied by a regex.
i already have the
+version+ var that i set manually and is used to configure other things
/^[0-9]+\.[0-9]+\.[0-9]+$/, i'd never make a tag like that other than for a release
@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
pom task could merge properties into an existing pom.xml if one is present in the fileset
I think you need more than just the number, you need to select a tag type, e.g. MVN, to avoid conflicts.
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.
like applications won't be dependencies, so the requirements there are far less rigorous
yes but at least in some cases I'd like to drive them from version control. maybe. I think. ;)
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.
the app/lib distinction is another thing lost on most tools, that leads to lots of unneccesary typing imo
@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.]+"))
But a default of
(def +version+ (boot.git/derive-version-from-tag)) could be provided via another fn form
@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
what if I have some tag that matches but is not intended as an mvn version tag? I may be misunderstanding.
@mobileink: that's why I'm sort-of proposing you could provide a regex that would match only your mvn version tags
but actually I agree with @micha this is a corner-case - mostly a tag like 1.2.8 is pretty obviously a version
but boot is so flexible - this conversation is kind of academic because boot right now is agnostic (which I like)
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)
it's no secret my company juxt are rooting for boot to succeed and (slowly) migrating many of our client projects over to it
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.
When I do
boot watch notify test I quickly get
Exception in thread "Thread-37" java.lang.OutOfMemoryError: Metaspace
@alandipert posted this link in the adzerk slack yesterday, might be useful for that exception: https://stuartsierra.com/2015/05/27/clojure-uncaught-exceptions
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?
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.
hmm i one sec let me look at the uber task implementation again, it has the answer you need
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.
aha! yes, somebod needs to docs. ;) maybe me if I can get this working when I get back to the fortress of somnitude.
ah i was wrong above, the
:checkouts key is just the deps you set with
--checkouts option of course
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.