Fork me on GitHub
#boot
<
2016-09-26
>
xla01:09:25

Sorry @micha - just saw your message. Thanks for your response but I already figured out what caused the issue: https://clojurians.slack.com/archives/boot/p1474805564003599

borkdude10:09:31

Is there a way of writing this in one statement?

(set-env! :dependencies #(conj % '[jsofra/data-scope "0.1.0"
                                   :exclusions [clj-time
                                                slingshot]]))
(set-env! :dependencies #(conj % '[clj-time "0.12.0"]))
(set-env! :dependencies #(conj % '[slingshot"0.12.2"]))

borkdude10:09:34

ok, I guess I could do with only one set-env!:

borkdude10:09:38

(set-env! :dependencies '[[jsofra/data-scope "0.1.0"
                           :exclusions [clj-time
                                        slingshot]]
                          [clj-time "0.12.0"]
                          [slingshot "0.12.2"]])

dominicm10:09:08

@borkdude I often use concat for that

dominicm10:09:25

If I'm adding to a list of already set deps anyway

borkdude10:09:04

It seems set env is updating, not replacing? Not sure

martinklepsch10:09:44

@borkdude if you pass a function it's updating, if not (i.e. just a dependency vector) it's replacing

manenko12:09:52

I want to restrict a set of values for an option. Is it achievable using boot task options DSL?

martinklepsch12:09:48

@manenko: I don't think so, you need to add an explicit assert

manenko12:09:44

understood 🙂 thank you

micha13:09:02

@borkdude it's not really possible to remove a jar from the classpath once it's been loaded

micha13:09:22

so set-env! can only add more jars, it can't actually replace anything

micha14:09:04

however, the :dependencies vector is replaced when you do (set-env! :dependencies '[[foop "123"]])

borkdude14:09:29

@micha so set-env!loads them every call and doesn’t batch it?

micha14:09:04

@borkdude right, set-env! acts synchronously

dominicm15:09:26

@micha seems like calling set-env! without concat would bork your pom?

tianshu15:09:02

I have a boot project, and I want to deploy it with jenkins. Should I find a plugin for jenkins or convert my project to a maven project?

micha15:09:33

@dominicm yeah depending on what you expect to be in there

micha15:09:10

i guess the correct thing would have been to make it strictly append only

dominicm15:09:17

I think this is better. I actually think I might be able to do some evil neat things with it

pesterhazy16:09:11

@doglooksgood never use plugins in jenkins

pesterhazy16:09:35

just use the shell build step and run boot dist or whatever from there

pesterhazy16:09:28

don't get me wrong, I like jenkins, but there's absolutely zero reason to use jenkins plugins for anything unless it adds some sort of UI element

pesterhazy16:09:18

your goal should be to replicate what you do manually when you cut a release from your laptop, almost exactly

pesterhazy16:09:40

anyway, that's my opinion 🙂

borkdude16:09:00

How do I call a task from the REPL. E.g. (deftask foo [d dude bool “dude or not”] (println d))

tianshu16:09:11

@pesterhazy In this case, I have to install boot on all server. Is it possible to avoid this? I mean I may develop with boot, but dist with maven?

pesterhazy16:09:33

Installing boot on the server is a matter of installing a single shell script

pesterhazy16:09:04

You can even include it in your repo

tianshu16:09:30

That's a good idea

dimovich16:09:41

hello fellow booters

dimovich16:09:05

having some difficulties with running boot after switching to latest cljs / clj releases

dimovich17:09:27

any advice would be appreciated

juhoteperi17:09:16

@dimovich namen/core.cljs is most probably missing some end parenthesis

urbanslug17:09:31

Hey shouldn’t :target “target" make boot use target/ as the target dir?

urbanslug17:09:01

oh :target-path

micha17:09:20

@urbanslug which version of boot?

dimovich17:09:50

@juhoteperi yeah, you were right 🙂

urbanslug17:09:56

@micha 2.6.0

urbanslug17:09:36

Even target-dir didn’t work

urbanslug17:09:40

boot.properties

BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.6.0
BOOT_EMIT_TARGET=no
build.boot
(set-env! :source-paths #{"src"}
          :dependencies '[[adzerk/boot-cljs "1.7.170-3"]]
          :resource-paths #{"html"}
          :target-path "target")

;; makes the cljs task visible to the boot.
(require '[adzerk.boot-cljs :refer [cljs]])

micha17:09:14

@urbanslug the :target-path key was removed in 2.6.0, there is a target task instead

urbanslug17:09:38

Now I have to deftask or what?

urbanslug17:09:48

SMH such high barrier for entry

micha17:09:55

no you just add the target task at the end of your pipeline

micha17:09:02

like if you were doing boot foo bar before

micha17:09:11

you can do boot foo bar target now

micha17:09:41

ah yeah that wiki page is out of date

micha17:09:56

there is the note at the top though

micha17:09:01

that describes the situation

urbanslug17:09:01

I don’t get it. I can’t just specify it in build.boot?

micha17:09:13

writing files to a directory is now just another task

micha17:09:22

it's not a special thing in boot anymore

micha17:09:09

the reason for this is because it's actually quite rare to write files to a target dir nowadays

juhoteperi17:09:23

@urbanslug (comp (foo) (bar) (target))

micha17:09:36

yes that ^^

urbanslug17:09:56

@micha Ok please tell me what are people doing nowadays?

urbanslug17:09:11

I probably shouldn’t be using a target

urbanslug17:09:22

The moderncljs tuts don’t seem to care much about it

juhoteperi17:09:49

Pretty much only usecase for target task is when you need to get the Jar file for deployment etc.

micha17:09:05

well usually you will want to run tests or a local dev server or something when you're developing your application, and neither of those need files in a target dir (they use the classpath)

micha17:09:18

for production you usually will have some task that deploys the artifact

micha17:09:32

like uploading things to s3 or whatever

micha17:09:54

the only time i use the target dir is like deraen says, to get a jar file

urbanslug17:09:30

@micha Thanks for teaching me that. I want to ask so many questions rn but I’ll read the tutorial.

urbanslug17:09:50

So the local dev server will just find the output?

micha17:09:14

yeah it can serve files from the JVM classpath

micha17:09:52

that's how it works when you have a server that's serving files from an uberjar

urbanslug17:09:00

They seem to be under ~/.boot

urbanslug17:09:10

I hope that’s the classpath you are referring to

micha17:09:13

yeah in dev the classpath will include directories

micha17:09:23

but you don't need to know about the .boot dirs

micha17:09:40

for example, if you have (set-env! :resource-paths #{"src"})

urbanslug17:09:50

Ok I notice this tuts assume having used the jvm before.

micha17:09:58

and you have a file in your project src/foo/core.clj

urbanslug17:09:14

Which I do but .cljs

micha17:09:22

you will be able to access that file via the classpath like this:

micha17:09:37

( "foo/core.clj")

micha17:09:09

the classpath is important to understand, at least in a general way

micha17:09:44

the purpose of it is to provide a level of abstraction above the resources your program needs

urbanslug17:09:49

heh when I gooogle classpath I get results that assume one knows that it is

micha17:09:38

like the foo/core.clj file could be in a jar file, it could be a file in a directory on your machine, or it even could be a http URL somewhere on the internet

micha17:09:13

there are different ways to add things to the classpath, but one way to read them

micha17:09:17

this is really powerful

micha17:09:44

so if you have a program that needs foo/core.clj it doesn't need to know or care where it comes from or how it got there

micha17:09:56

it only needs to know its path

urbanslug17:09:05

to know it’s classpath

urbanslug17:09:13

and the classpath is like some virtual path

urbanslug17:09:18

that is not the actual path

micha17:09:34

it's called "classpath" because the JVM load classes from class files (the JVM compiled bytecode)

micha17:09:59

so if you have a class foo.Bar, there will be a file on the classpath with the path foo/Bar.class

micha17:09:23

does it care if that class file is packaged in a compressed jar file? nope

urbanslug17:09:44

So the classpath is really just a single dir with all the modules/namespaces I require

micha17:09:48

it could be in a jar file, it could be somewhere on the internet, or it could be in a local file in the filesystem

micha17:09:58

yeah more or less what you said

micha17:09:12

there are some nuances, but that's a good first order approximation 🙂

micha17:09:30

however, it's not about require

micha17:09:44

it might help to think about what require does

micha17:09:59

when you have (require 'foo.core) in clojure

micha17:09:06

the following happens (more or less)

micha17:09:46

the require function looks at the foo.core symbol and derives a path that is established by convention

micha17:09:02

that path will be foo/core.clj

urbanslug17:09:14

and not clj(s/c) ??

micha17:09:27

well there are nuances, yes

micha17:09:38

like it also looks for precompiled class files

micha17:09:40

and so on

micha17:09:52

but let's pretend those don't exist for now 🙂

micha17:09:12

so require needs to find a clojrue source file and compile it

micha17:09:21

so it looks on the classpath for foo/core.clj

micha17:09:52

it reads the contents of that resource and compiles it into JVM classes etc

urbanslug17:09:07

and the classpath is in a" decided by convention dir" my project root, right?

micha17:09:15

negative 🙂

micha17:09:31

so let's think about where foo/core.clj might come from

micha17:09:48

it could be part of a jar file you added to the classpath as a dependency

micha17:09:59

like maybe you're using the foo library from Maven

micha17:09:14

and the foo-1.2.3.jar jar contains the core.clj file

urbanslug17:09:19

or it could be in my src/

micha17:09:34

so there is no convention that boot knows about

micha17:09:51

you add directories to the classpath in almost the same way as you add dependencies

micha17:09:12

(set-env! :resource-paths #{"src/clj" "src/cljs"})

micha17:09:14

for example

micha17:09:40

the contents of those two directories will be "overlayed" and the files in there will be accessible on the classpath

micha17:09:49

at their relative paths

urbanslug17:09:59

ha! so the classpath is really just a set of paths to either source files or jar files

micha17:09:07

not exactly

micha17:09:09

but almost

micha17:09:19

the classpath is a map of path to URL

micha17:09:04

so like foo/core.clj might map to the url file:/home/micha/.m2/repository/foobar/foobar-1.2.3.jar!foo/core.clj

micha17:09:21

or something like that, i forget how the jar entry urls look exactly

micha17:09:39

when i add a jar to the classpath it adds each jar entry

micha17:09:57

so all the files in the jar archive have their mappings in the classpath

micha17:09:24

so suppose you want to just print out the contents of the foo/core.clj file

micha17:09:26

from the classpath

micha17:09:46

(println (slurp ( "foo/core.clj")))

urbanslug17:09:10

When I download a dep it’s modules/namespaces will be added to the classpath for that project.

micha17:09:30

well boot has these "pods"

urbanslug17:09:42

I saw the word pods

urbanslug17:09:47

No idea what they were

micha17:09:51

which are a mechanism by which you can have separate, independent, isolated classpaths

urbanslug17:09:02

To prevent conflicts.

urbanslug17:09:06

Sandboxes huh?

micha17:09:07

precisely

micha17:09:25

you may need version 1 of some jar for one task, and version 2 for a different task

micha17:09:47

instead of being in a checkmate catch-22 situation you can isolate the two versions in different pods

micha17:09:02

so the main type of classloader you'll see is the URL classloader

micha17:09:45

you can configure the classloader with URLs where it can find resources

urbanslug17:09:01

Sorry my internet connection is bad

micha17:09:02

so when you do (io/resource "foo/core.clj") it will search the URLs

urbanslug17:09:05

I went offline

urbanslug17:09:42

hmmm but boot does this classloader configuring for us, right?

urbanslug17:09:11

or at least whatever dependency management system it is using underneath

micha17:09:36

the basic idea you probably need to know is that the classloader is where the resources your program needs will be

micha17:09:47

the classloader mediates access to them, finds them, etc

micha17:09:19

every URL that's added to the classloader is itself a filesystem, essentially

micha17:09:30

a collection of files with corresponding paths

micha17:09:55

you access resources that are on the classpath with function

micha17:09:17

you add jars or directories to the classpath with set-env! in boot

micha17:09:33

does that make sense?

micha17:09:09

it's kind of a weird thing to explain

urbanslug18:09:57

@micha It does

urbanslug18:09:16

It does sorry I thought you’d gone away after you took a while to reply

micha18:09:38

my internet also acting up today

urbanslug18:09:03

Ok so the dev server will just use the classloader to find the files

urbanslug18:09:33

and the files will be found by the classloader in the classpath because I added them in the resource paths

micha18:09:35

yeah there is a ring middleware for this, if you're using ring

urbanslug18:09:40

or under deps

urbanslug18:09:51

I want to use ring, yes.

micha18:09:56

wrap-resource is the one you want

micha18:09:12

the pandiero/boot-http boot task handles it for you

micha18:09:59

if you're going to deploy to an uberjar you'll need to have your ring stack handle this for you though

urbanslug18:09:25

I want to go through the entire build process from start to dev to deployment.

micha18:09:40

if you're comfortable with ring already then it should be relatively painless 🙂

micha18:09:05

so the first step could be to make a file src/index.html file

micha18:09:13

with like "hi world" in it

micha18:09:17

then you can do this

urbanslug18:09:26

I read the ring docs/wiki a while ago (a few months) so.. will have to get familiar with it.

micha18:09:54

boot -r src -d pandeiro/boot-http serve wait

micha18:09:04

no build.boot file or anything

micha18:09:25

that will get you a dev server on port 3000 with your html file served

urbanslug18:09:41

Ok simple enough but too simple for what I want to learn. I want to have a html file that requires js that actually uses om next to render graphs using c3. and well ring for the controller

urbanslug18:09:52

idk if I’m making sense

urbanslug18:09:06

I am quite far from the goal but it’s not too daunting a task.

urbanslug18:09:32

I hope to learn along the way how to get the repl working and stuff like uh whatever figwheel does

micha18:09:40

well crawl-walk-run right?

urbanslug18:09:48

I want to do this for the process not the end goal

micha18:09:06

so the simplest start is to serve one static html file

micha18:09:18

once that works you can take the next step

micha18:09:27

without wondering whether something basic is broken

micha18:09:52

so once that is working you can do this:

micha18:09:08

make a file src/app/serve.clj with these contents

micha18:09:49

(ns app.serve)

(defn handler [req]
  {:status 200
   :headers {"content-type" "test/html"}
   :body "i am alive"})

micha18:09:53

then you can do

micha18:09:15

boot -r src -d pandeiro/boot-http serve -H app.serve/handler wait

micha18:09:34

localhost:3000 should now say "i am alive"

urbanslug18:09:37

@micha This is using ring behind the scenes

micha18:09:51

boot-http does, yes

micha18:09:19

you can now make a build.boot file that incorporates the various command line args we use above:

urbanslug18:09:57

This is really good for debugging specific handlers

urbanslug18:09:02

Nope localhost:3000 attempts to download a file instead of serving html

urbanslug18:09:14

Should I have created a html file?

micha18:09:36

no, are you sure you have the :headers in your response map?

micha18:09:57

it needs to send content-type headers

urbanslug18:09:31

Let me check the request because I downloaded a text file saying I am alive. Basically fetched.

micha18:09:08

your handler function, it returns a map with the :headers {"content-type" "text/html"} info?

urbanslug18:09:51

Ha I see the error

urbanslug18:09:02

it was test/html not text

urbanslug18:09:06

I copied and pasted

micha18:09:51

so once that's going smoothly you can try making a build.boot file to incorporate the pattern you like

urbanslug18:09:13

It has gone smoothly

micha18:09:14

(set-env!
  :resource-paths #{"src"}
  :dependencies '[[pandeiro/boot-http "0.7.3"]])

(require '[pandeiro/boot-http :refer [serve]])

(deftask dev []
  (comp (serve :handler 'app.serve/handler) (wait)))

micha18:09:47

then you can do boot dev

urbanslug18:09:50

It’s weird that in boot files we require after set-env! I assume set-env is like a ns declaration

urbanslug18:09:01

or well setting the env for what will come later

micha18:09:04

set-env is to manipulate the classpath

micha18:09:13

require is to compile clojure

urbanslug18:09:14

oh for the rest to find it

micha18:09:20

yeah those are separate concerns

micha18:09:06

the require function actually compiles source code

micha18:09:26

but it doesn't know how to fetch that source code from dependencies or whatever

micha18:09:30

maven etc

urbanslug18:09:46

but it only fetches a function/module

urbanslug18:09:50

as far as I see

micha18:09:01

it compiles a single clojure source file

micha18:09:10

that it expects to be present on the classpath

micha18:09:20

how it gets on the classpath it doesn't know or care

urbanslug18:09:30

So require asks the classpath for the function/module then compiles it

urbanslug18:09:49

using the ns as the key

urbanslug18:09:58

OMG it’s falling into place

micha18:09:00

it does like (compile (read (resource "foo/core.clj")))

micha18:09:21

where resource resolves a file in the classpath given a path

urbanslug18:09:37

the reads it and then compiles

micha18:09:50

and read takes a resolved resource URL, reads the file, and returns clojure data s-expressions

micha18:09:59

and compile compiles that

urbanslug18:09:17

didn’t expect this part "returns clojure data s-expressions"

micha18:09:23

yeah i mean that's not exactly what require really does, but it's the idea

urbanslug18:09:30

I guess because it won’t have the spaces

urbanslug18:09:36

not the file itself

urbanslug18:09:45

Yes it’s a high level view of things

micha18:09:47

well that part was just illustration

urbanslug18:09:16

@micha Thanks for taking the time to explain that stuff to me.

micha18:09:52

so a thing that might be useful for you

micha18:09:10

you can get usage help for any task at the command line via task -h

micha18:09:20

like boot wait -h

micha18:09:24

for example

micha18:09:41

and if you're in the repl you can get help about how to use the task in clojure (like in your build.boot file)

micha18:09:51

boot.user=> (doc wait)

micha18:09:58

wait is a task, of course

micha18:09:29

so if you look at the boot-http example we did above

micha18:09:41

you can see how i knew which keyword options to use

micha18:09:50

and which command line options to use

micha18:09:24

like boot serve -H foo.bar/baz is same as (boot (serve :handler 'foo.bar/baz))

urbanslug18:09:47

@micha This should respond to boot serve -h shouldn’t it?

(set-env! :source-paths #{"src"}
          :dependencies '[[adzerk/boot-cljs "1.7.170-3"]
                          [pandeiro/boot-http "0.7.3"]]
          :resource-paths #{"html"})


(require '[[adzerk.boot-cljs :refer [cljs]] ; makes the cljs task visible to boot.
           [pandeiro/boot-http :refer [serve]]])

urbanslug18:09:04

Oh man the slash

micha18:09:28

ah right, the slash

urbanslug18:09:12

also I made them a vecot

urbanslug18:09:38

Should be many vector args to require.

urbanslug18:09:55

(require '[adzerk.boot-cljs :refer [cljs]]
         '[pandeiro.boot-http :refer [serve]])

micha18:09:56

actually i don't think so

micha18:09:03

yeah that's right

urbanslug18:09:07

Well that works and the before didn’t ^

micha18:09:15

the vector of vectors is not right

urbanslug18:09:36

Had to look at a build.boot file online haha

micha18:09:50

that's actually just the normal clojure.core/require function

micha18:09:00

nothing boot-specific there really

urbanslug18:09:04

Thanks 🙂 you just made it really easy for me to get me to thinking about this immediate feedback thing and getting a cljs repl to work.

lwhorton18:09:54

hey guys, if I just wanted to include a lib into my (clojurescript) output, and that lib has no external api, it just has a dependency on window.OtherLib, where would I start?

lwhorton18:09:22

I’m thinking about using the cljsjs-packaging download, but i’m not sure how to annotate the dependency on another lib. I suppose I could use deps-cljs and the :requires [“otherLib”], which would probably do it?

lwhorton19:09:34

i suppose my question is... normally if I were to make a separate cljsjs package out of this component, i would sift the files into the set, then pom + jar everything into a package. but in this case where its “internal”, what’s the appropriate steps to get this lib into the fileset (as opposed to pom + jar) so that I can (:require [somelib.foo])?

juhoteperi19:09:00

@lwhorton You could just add the JS files to your source dirs?

lwhorton19:09:13

after downloading the file, then (sift :mode #{“foo.js”} “somewhere/in/source/foo.js”), will that make it available via a (:require [foo.js])? I’m not sure how the edn file is created me thinks 😕

manenko19:09:48

Hello everyone. I want to get full path to a file in a fileset so that I can read the file. Is the following correct way of doing this?

(defn ^:private input-file-by-name
  [name fileset]
  (let [f (first (boot/by-name [name] (boot/input-files fileset)))]
    (io/file (:dir f) (:path f))))

lwhorton19:09:52

@manenko the idea behind boot is that the “full path” is never really known, it’s always some temporary object wrapper. you use (tmp-file f) or (tmp-path) to get a handle to the actual file object/path.

lwhorton19:09:35

every operation interacting with a “boot file” (not a normal io/file) should do so through the boot file api, which provides an abstract interface

lwhorton19:09:00

a very common patter I find myself writing is something like this:

(doseq [in files]
            (let [in-file (c/tmp-file in)
                  in-path (c/tmp-path in)
                  out-path (.replaceAll in-path "\\.styl$" ".css")
                  out-file (io/file tmp out-path)]

manenko19:09:18

I have a zip file I downloaded in the ‘previous task’ and I want to extract it. Are you saying I should use (tmp-file zip-filename-generated-by-other-task) to read the file content?

lwhorton19:09:17

the download task does come with an :unzip, but i’m not sure where it dumps them (not sure if they’re added to the fileset or not): https://github.com/cljsjs/boot-cljsjs/blob/master/src/cljsjs/boot_cljsjs/packaging.clj#L37

lwhorton19:09:57

on second look it seems that it does add those to the fileset

manenko19:09:33

Yeah, I’ve seen that. The problem is that their unzip doesn’t preserve posix file permissions 😞

lwhorton19:09:12

hmm.. bummer. regardless, if you have your own task that adds them to the fileset, you would then do some fileset query to find the files you’re looking for

lwhorton19:09:50

that would give you the boot files, and then use the file api to get the real files, but im not sure if that would preserve the metadata either.

manenko19:09:37

Understood. Thank you

lwhorton19:09:14

np, it took me a long time to wrap my head around, and I still don’t get 100% of it, but it sure beats the alternative imo.

manenko19:09:22

True. The documentation could be better though :]

micha19:09:29

@manenko there are also convenience functions: boot.core/tmp-file and boot.core/tmp-path

micha19:09:36

oh sorry, my slack window was not updating for some reason

manenko20:09:22

It seems boot doesn’t preserve files attributes (posix permissions, for example) when it copies them to target folder 😞

kenny22:09:20

@seancorfield In boot-new is it possible to get the version numbers auto filled in with the latest version instead of RELEASE?

seancorfield23:09:12

Not at present — create an issue on GH with details of what functionality you’d like and I’ll take a look.

seancorfield23:09:43

(my thinking was you’d just update the build.boot file in the generated project)

kenny23:09:11

I do that every time after I generate a project using boot-new 🙂

seancorfield23:09:44

The reason the templates use "RELEASE" is so whatever project you generate will not be tied to whatever old version (of Clojure etc) happened to be current when I wrote the templates 🙂

kenny23:09:51

Just thinking it'd be more convenient for it to be done automatically when boot-new generates the project

seancorfield23:09:23

So you’d want the default version to match whatever version of Clojure was used to run boot-new in the first place?

seancorfield23:09:11

'k … create an issue on GH for boot-new and I’ll think about the best way to handle that (since I prefer the "RELEASE" behavior by default 🙂 )

kenny23:09:18

But, more generally, I would want it to fetch the latest version of any library and replace the version number

seancorfield23:09:39

That’s what "RELEASE" does.

kenny23:09:52

But the version number is still RELEASE

kenny23:09:11

And if you don't replace RELEASE you can get inconsistent builds

kenny23:09:33

RELEASE was actually removed from maven 3 for that reason

seancorfield23:09:41

But boot-new isn’t going to go looking for libraries and trying to determine their version — it’s just processing text files.

seancorfield23:09:35

So even if boot-new defaults to writing the same Clojure version into the generated file as boot-new itself was run with, it has no idea about any of the other libraries in a generated text file.

kenny23:09:39

I was thinking you would need to write your deps in such a way that it would know to fetch the latest version and replace that string

seancorfield23:09:52

Boot new is just a text processor.

seancorfield23:09:07

The templates are just text. They can have any text in them.

kenny23:09:09

Ah. I thought the purpose was to automate creating new projects

seancorfield23:09:26

Yes, and there are lots of templates out there.

seancorfield23:09:55

The built-in ones are "trivial" and only likely to be used for toy projects.

seancorfield23:09:37

Right, an individual template can choose what versions to produce.

kenny23:09:52

That's exactly what I was thinking

seancorfield23:09:41

Note: Hoplon has a dependency on ancient-clj which I’m not dragging into boot-new just for this 🙂

kenny23:09:41

It could be lazily loaded, no?

kenny23:09:00

If you want the functionality you add a flag and add ancient-clj to your deps

micha23:09:33

boot also has such functionality built in

micha23:09:58

the hoplon template uses ancient-clj there from when it ran in leiningen

micha23:09:38

but yeah i agree with @seancorfield it's really easy to do it in your template

kenny23:09:55

Just would be cool to have in there by default. For example:

(set-env! :resource-paths #{"src"}
          :source-paths   #{"test"}
          :dependencies   '[["{{dep}}org.clojure/clojure{{/dep}}"]])
It would replace {{dep}}{{/dep}} with the symbol and its latest version

seancorfield23:09:21

I don’t think it’s worth doing for the built-in templates since they’re so minimal (except perhaps for picking a specific Clojure version — and adzerk/boot-test is the only other dependency in the built-in templates and that’s only for testing anyway so you probably do want to make sure you get the latest version).

seancorfield23:09:59

(actually there’s boot/core and seancorfield/boot-new in the task and template templates respectively… but I still don’t think those are worth changing since the templates are so minimal and you’re going to be adding all sorts of your own dependencies anyway)

kenny23:09:47

But that same snippet I posted could be used for any dependency, not just clojure

seancorfield23:09:27

Defaulting the Clojure version in the generated templates is a bit of a moot point tho’ since the version that Boot starts will override it regardless — unless you’re generating an uberjar

seancorfield23:09:39

If you feel strongly that it’s worth doing, feel free to put together a Pull Request (that doesn’t drag in any external dependencies — since @micha says Boot already includes the functionality you’d need).

seancorfield23:09:12

And remember, this is purely for the built-in templates — what any other template chooses to do is up to them.

kenny23:09:30

Makes sense. If I have time, I'll look into submitting a PR later today. I think it would definitely help further automate the new project workflow.

kenny23:09:12

Without adding any new dependencies simple_smile