Fork me on GitHub
#boot
<
2016-01-11
>
jethroksy03:01:35

@micha do you deploy with eb deploy or using the boot plugin?

micha03:01:13

i've been using eb deploy

jethroksy03:01:51

i'm using eb deploy but the docker images created are extremely weird

jethroksy03:01:19

I get no such task: /usr/bin/boot in my sdeouterr.log

jethroksy03:01:36

then i check the docker images log and see that the command is /usr/bin/boot /usr/...

micha03:01:40

does the docker image run locally?

micha03:01:03

that's weird

jethroksy03:01:51

I removed all appearances of /usr/bin/boot in my dockefile

jethroksy03:01:07

and its still creating images with /usr/bin/boot /usr/.. as the command

micha03:01:20

do you have a dockerrun.aws.json file?

jethroksy03:01:56

{
    "AWSEBDockerrunVersion": "1",
    "Ports": [
	{
	    "ContainerPort": "3000"
	}
    ],
    "Volumes": [],
    "Logging": "/var/log/nginx"
}

micha03:01:54

it's weird that it runs locally

micha03:01:09

docker image should eb a docker image

micha03:01:20

that's the whole point of them lol

jethroksy03:01:07

yeah... i'll try running it locally again to see if i broke something

jethroksy03:01:58

local image works...

Current system: #'edubot.systems/prod-system
03:31:38.601 INFO  [org.projectodd.wunderboss.web.Web] (clojure-agent-send-off-pool-0) Registered web context /
Autostarting the system: :started
Reloading namespaces (edubot.pages.signup edubot.systems edubot.pages.partials edubot.slack edubot.core edubot.handler edubot.pages.errors edubot.pages.index)
:reloading ()
03:31:39.054 INFO  [org.projectodd.wunderboss.web.Web] (clojure-agent-send-off-pool-0) Registered web context /

danielsz03:01:07

Public announcement: the latest system snapshot supports abstractions derived from Duct: endpoints and handlers. Discussion around the upcoming changes is here: https://github.com/danielsz/system/issues/48

micha03:01:59

congratulations, @danielsz

micha03:01:13

looks great

jethroksy04:01:53

@micha: I cloned https://github.com/danielsz/holygrail and am trying to deploy it to EB

jethroksy04:01:39

So I cloned, did eb init with all the usual stuff

jethroksy04:01:42

Dockerfile:

FROM adzerk/boot-clj:latest

RUN /usr/bin/boot web -s doesnt/exist repl -e '(System/exit 0)' && rm -rf target

# Application
WORKDIR /app

EXPOSE 8008
CMD ["prod-run"]

jethroksy04:01:25

Dockerrun.aws.json:

{
    "AWSEBDockerrunVersion": "1",
    "Ports": [
	{
            "ContainerPort": "8008"
	}
    ],
    "Volumes": [],
    "Logging": "/var/log/nginx"
}

jethroksy04:01:27

I thought the boot-clj image made the ENTRYPOINT /usr/bin/boot so the CMD ["prod-run"] would run /usr/bin/boot prod-run

micha04:01:45

well maybe

micha04:01:57

i forget now

jethroksy04:01:00

but building it locally gives no such task: (prod-run)

micha04:01:18

i usually set the ENTRYPOINT in my dockerfile

jethroksy04:01:47

so would you do ENTRYPOINT ["/usr/bin/boot", "prod-run"]

jethroksy04:01:25

if it were ENTRYPOINT ["/usr/bin/boot", "repl"]

jethroksy04:01:45

would CMD ["(go)"] run (go) in the repl for example?

micha04:01:04

no, i don't see how it would do that

micha04:01:21

i don't really understand the relationship between ENTRYPOINT and CMD

micha04:01:32

it used to be that they were interchangeable

jethroksy04:01:42

CMD provides the default params for ENTRYPOINT

jethroksy04:01:48

if ENTRYPOINT is set

micha04:01:28

where are the parens coming from?

micha04:01:36

no such task: (prod-run)

micha04:01:13

there is an option to the repl task btw

jethroksy04:01:30

i have no idea

micha04:01:31

boot repl -e '(go)' will work

micha04:01:48

if go is referred into your build.boot namespace

jethroksy04:01:05

changed Dockerfile to ENTRYPOINT ["/usr/bin/boot", "prod-run"]

jethroksy04:01:24

still get that

clojure.lang.ExceptionInfo: java.lang.IllegalArgumentException: No such task (prod-run)
    data: {:file "/tmp/boot.user2351824110130883549.clj", :line 7}

micha04:01:07

don't worry about the parens

micha04:01:37

$ boot asdfasdf
 clojure.lang.ExceptionInfo: java.lang.IllegalArgumentException: No such task (asdfasdf)

jethroksy04:01:54

so i would need to do all the ADD build.boot ... stuff

micha04:01:24

i suppose so

micha04:01:38

i have i think ADD . usually

alandipert04:01:28

something looks amiss with show of late:

alan@cheezit:~$ BOOT_VERSION=2.4.2 boot -d javax.servlet/servlet-api:2.5 uber -j show -f
Adding uberjar entries...
servlet-api-2.5.jar
alan@cheezit:~$ BOOT_VERSION=2.5.5 boot -d javax.servlet/servlet-api:2.5 uber -j show -f
Adding uberjar entries...
69ca51af4e9a67a1027a7f95b52c3e8f-servlet-api-2.5.jar

micha04:01:41

maybe it's -d related

micha04:01:19

wait what is the correct behavior?

micha04:01:23

that looks ok

micha04:01:45

i guess it should have dependencies or something?

alandipert04:01:57

servlet-api-2.5.jar vs 69ca51af4e9a67a1027a7f95b52c3e8f-servlet-api-2.5.jar

micha04:01:08

oh that's just the name

micha04:01:18

to prevent collisions

micha04:01:26

the md5sum should be the same

alandipert04:01:47

oh this is an uber improvement i missed?

alandipert04:01:07

and yeah i think this is pre-`-d` update

micha04:01:07

the first part is the md5sum of the jar itself

micha04:01:39

because if you have a bunch of jars in WEB-INF/lib/ there might be two with the same name

micha04:01:21

is adding the md5sum to the name interfering with something?

alandipert04:01:39

no i just didn't expect to see it

alandipert04:01:00

thought it might be a toString regression on tmpfile or something

alandipert04:01:35

but now i abide it

alandipert04:01:36

mystery solved

be907:01:20

hm, I tried to upgrade to boot-reload 0.4.3 and it flunks with:

clojure.lang.ExceptionInfo: Could not locate adzerk/boot_reload__init.class or adzerk/boot_reload.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.
Changing 0.4.3 back to 0.4.2 works.

juhoteperi07:01:29

Sorry, bad release

be908:01:14

well, it happens simple_smile

michal09:01:31

hi. i’m trying to figure out how to exclude boot/core and adzerk/bootlaces dependencies from POMs generated by build-jar (from bootlaces). no luck so far. any hints?

martinklepsch09:01:58

@michal: is it important to you that they're not loaded as transitive deps or is it really about not leaving any trace in Pom.xml?

michal09:01:40

well, the latter would be preferable, but if it’s a problem it would be enough just to not enforce downloading these deps

martinklepsch09:01:27

I can't tell you how to do the latter right now but if you add :scope "test" to a dependencies vector it will not be registered as a transitive dependency

michal09:01:03

good point. i forgot about scopes. thanks Martin.

magomimmo09:01:27

does the need of keeping :source-paths and :resource-paths separated has to do with scenarios in which you don’t want your source code be included in the jar or there are other use cases in which keeping them separated is recommended?

michal09:01:49

i would rather say that resource-paths are directories bundled to resulting jar from where you can read your files (resources) in runtime and source-paths are used by boot just to locate source files to compile

martinklepsch09:01:51

Also always helpful to look at the fileset roles documentation in the wiki

magomimmo09:01:01

@martinklepsch: and re-reading more times simple_smile

martinklepsch09:01:12

@magomimmo: in a cljs project you might build a zip at the end in which you don't want to include your sources

magomimmo09:01:21

@martinklepsch: yes I know. I was listing in my head all the different scenarios. and the one cited by you is one of them

alandipert14:01:09

@ragge: out of curiousity do you have any opinion on nix vs guix?

ragge14:01:27

@alandipert: I've never used guix and have only read briefly about it so can't say much

ragge15:01:38

@alandipert: but nix is great simple_smile

onetom15:01:00

@jethroksy: @micha: looks like there is a lot of problem w docker, no?

onetom15:01:11

has anyone tried to run clojure apps using http://osv.io/amazon-ec2/ ?

micha15:01:40

i think @alandipert has experimented with this?

alandipert15:01:37

i haven't tried that

jethroksy16:01:34

@onetom: might try that tomorrow, but i think only I get docker problems 😩

alandipert17:01:28

hi @cloudroutine welcome 👋

cloudroutine17:01:31

i'm an interloper here to lurk and steal ideas 😉

cloudroutine17:01:46

I found out about boot for the first time today. I've been tasked to create a new build system for F#, so I'm surveying other languages to see what might be useful

martinklepsch17:01:12

look no further hahaha

martinklepsch17:01:23

& welcome simple_smile 😉

cloudroutine17:01:10

middleware-factories are a bit 😕

dm317:01:28

should set-env! :dependencies be enough to pull the dependencies from the repl?

dm317:01:19

or is another action required?

martinklepsch17:01:45

@dm3: should be enough. merge-env! might be better if you don't want to list all existing dependencies as well

martinklepsch17:01:32

@cloudroutine: maybe middleware factories doesn't sound like much fun but middleware factories is not something users/devs think about much. I think it's just an attempt at describing what tasks are. You could also say they're higher order functions simple_smile

alandipert17:01:25

@cloudroutine: middleware factories are a key part of how boot can be efficient up against Make-style dependency-directed things

alandipert17:01:05

they provide a closure in which instances of a task can store mutable state - primarily, a cache

alandipert17:01:36

although i can imagine other systems for providing instances of tasks places to store caches... the nice thing about generating a function is it (and the place it uses) are anonymous

cloudroutine17:01:59

it seems like they're not particularly... well defined

micha17:01:02

the contract is pretty simple

micha17:01:12

everything else is left to the discretion of the user

micha17:01:34

boot simply provides useful libraries

cloudroutine17:01:37

haha yea "here's the part where who knows what'll happen" 😀

micha17:01:39

but doesn't force you to use them

micha17:01:54

that's exactly the point, in fact

micha18:01:03

boot can't know what you will need in advance

micha18:01:16

it gives you the means to program your build

cloudroutine18:01:37

it's such a jargony name I wasn't sure if I was missing something about it

micha18:01:41

the only contract is one of interop between tasks

micha18:01:55

that's why middleware and fileset and so on

micha18:01:11

to ensure that tasks can be composed uniformly

martinklepsch18:01:35

@cloudroutine: would be curious what other interesting tools you stumble upon btw simple_smile

cloudroutine18:01:50

do you know FAKE?

cloudroutine18:01:41

it's not as strongly typed as i'd like

cloudroutine18:01:50

I can kind of do what I need with it, but what I'm working now is going to end up being its sibling

alandipert18:01:01

make and boot are definitely opposite ends of the spectrum.. but both the same in that they are systems for linearizing effects

alandipert18:01:20

the boot way is, linearization happens like with any programming language - application via reducible expressions that can evaluate to a FileSet

alandipert18:01:45

vs. make which is an algebra for describing the order things should happen to an implicit file system value

cloudroutine18:01:28

in that sense FAKE is closer to boot than make

alandipert18:01:37

in that case it sounds awesome, i'll check it out simple_smile

alandipert18:01:52

thrown off by the name hehe

cloudroutine18:01:06

what's currently holding it back is how strongly tied it is to the msbuild system

cloudroutine18:01:15

so i'm tearing that out

cloudroutine18:01:41

so people on osx and linux can finally get a decent non-ide experience with F#

micha18:01:48

boot isn't tied to any build system

micha18:01:53

boot isn't even really a build tool

martinklepsch18:01:05

it's fairy dust

micha18:01:27

it simply provides the bootstrapping necessary to run clojure on the jvm and install maven dependencies that that code needs

micha18:01:54

and it provides libraries of its own that have useful functions for doing some common tasks with building clojure projects

micha18:01:05

which you can use in your clojure program that boot will run

micha18:01:15

your clojure program is the build tool

micha18:01:55

this is all stuff provided by libraries, which you can use or not use

micha18:01:13

and notice that it's just a process description

micha18:01:21

there is nothing specific to building there

micha18:01:41

that's a diagram of a sequential process

jaen18:01:07

So boot is boot is just a monoid in category of build systems? ; d

cloudroutine18:01:15

involving resource, source, and asset paths as a part of a virtual file system

micha18:01:31

there is no virtual filesystem though

micha18:01:45

there is an immutable fileset record type

micha18:01:00

which is a description of the real filesystem basically

micha18:01:12

but it is not a filesystem itself

micha18:01:51

the resource, source, and asset paths is part of the bootstrapping process

micha18:01:58

setting up the jvm classpath

cloudroutine18:01:30

@jaen I guess it's just fancy plumbing 😄

jaen18:01:56

All programming is fancy plumbing to a certain degree ; d

micha18:01:12

the real thing that boot does is get your code running, without an IDE or other tooling

micha18:01:25

you can make a shebang script with boot as the interpreter for instance

micha18:01:06

there is a lot of stuff that has to happen before clojure can run, especially around setting up the classpath

cloudroutine18:01:12

> the real thing that boot does is get your code running, without an IDE or other tooling ^ this is what I think of when I think of build system, maybe we're thinking of different things

micha18:01:27

well compare maven to boot, for example

micha18:01:34

i have a page of clojure expressions

micha18:01:38

i want to evaluate them

micha18:01:45

they need dependencies to run

cloudroutine18:01:48

I know zero about maven

micha18:01:58

or any of them

micha18:01:19

you can't do what boot does with make, for instance

micha18:01:00

because your program might have dependencies that are not statically known

jaen18:01:52

I guess one way to look at it

jaen18:01:03

Is that boot is to build tools what xmonad is to tiling window managers.

cloudroutine18:01:12

I haven't come across anything in boot so far that I couldn't implement in F#

jaen18:01:17

Not a specific implementation, but a library that lets you build your own.

micha18:01:03

there is nothing complicated about boot, i would be surprised if there was anything that couldn't be done in f#

micha18:01:29

i mean other than some things we need to do with the classpath

micha18:01:46

which is JVM and Clojure specific type of problems

cloudroutine18:01:49

i'm not sure if I want to do something like the pods or not

cloudroutine18:01:51

it might be useful to have that kind of isolation mechanism, but I don't think it'd need to be a strickly enforced since F# package manager is pretty good at resolving dependencies

micha18:01:23

the issue pods solve is when you have conflicts that can't be resolved

micha18:01:51

like when you actually need a different version of a dependency in one part of the program and a different one in the other

micha18:01:01

this is very common with build tasks, for example

cloudroutine18:01:17

I haven't programmed in java for over 10 years, it has binding redirects right?

micha18:01:31

not sure what that is

micha18:01:41

i don't think java has them simple_smile

cloudroutine18:01:15

> when you actually need a different version of a dependency in one part of the program and a different one in the other ^ when this happens you say 'no I want you to use the other one instead'

micha18:01:44

and you are then going to have to fix all the code that is now broken in any dependencies that need the other version

micha18:01:01

which is impractical because it may be some huge project like apache commons

micha18:01:05

or guava or whatever

micha18:01:09

thousands of classes

cloudroutine18:01:00

hmm this seems like a much more of a java specific issue

micha18:01:18

this is a common problem in clojure, where you have dependencies that are only needed at build time, but not at runtime, like the cljs compiler for example, which depends on some rally huge google project, which depends on a huge apache project, which depends on an old version of some http client

micha18:01:37

in your actual application you also need a http client

micha18:01:43

of an incompatible version

cloudroutine18:01:49

and there isn't a great way to do transitive dependency resolution?

micha18:01:54

no there is

micha18:01:01

but it's not a problem that can be solved that way

micha18:01:12

the google thing needs version 0.1 for example

micha18:01:18

and your application needs version 5.7

micha18:01:24

and the two are not compatible

micha18:01:30

so you can't just"pick the right one"

micha18:01:47

because if you do then you will break either one or the other

micha18:01:02

this is extremely common with build tasks

micha18:01:20

so in boot if you make a task, you're expected to load all your dependencies into a pod

cloudroutine18:01:20

yea so they're in separate dependency chains

micha18:01:39

so your dependencies are isolated from the rest of the environment

micha18:01:54

boot tasks have no transitive dependencies

micha18:01:05

they pull their deps in at runtime and install them in a pod

cloudroutine18:01:21

you couldn't load both 0.1 and 5.7 into the same domain?

micha18:01:42

no, how could you?

cloudroutine18:01:54

you can do that in .net

micha18:01:09

if i do new Foo();, how does it know which version of Foo to use?

cloudroutine18:01:29

you extern alias it

micha18:01:47

what about code that you don't control?

micha18:01:54

like this dependency is already compiled

micha18:01:59

and i can't extern alias anything

micha18:01:12

that's the real problem

micha18:01:16

not your own code

micha18:01:09

also manually managing transitive dependencies is not what i want

micha18:01:27

pods allow the simplest, most naive way to work reliably

micha18:01:52

don't think about how to merge conflicting dependency graphs, just isolate them in pods

micha18:01:56

it's extremely rare in boot to see issues with build task transitive deps

cloudroutine18:01:44

which seems like a nice thing about pods, I'm wondering if I could do something similar with compilation units for a more modular approach to assembly construction

cloudroutine18:01:47

which i guess would fall somewhere in between the boot and cargo approach

juhoteperi18:01:52

What is the package manager for f#? Paket?

juhoteperi18:01:50

From readme I understand that it works like Maven, it always selects a single version of dependency to load if there are multiple dependencies to it

juhoteperi18:01:06

> Even more importantly: If two packages reference conflicting versions of a package, NuGet will silently take the latest version (read more). You have no control over this process. > Paket on the other hand maintains this information on a consistent and stable basis within the paket.lock file in the solution root. This file, together with the paket.dependencies file enables you to determine exactly what's happening with your dependencies.

juhoteperi18:01:43

Groups look maybe a bit like Maven scopes

juhoteperi18:01:08

At least in a sense that they can be used to separate build and test deps

cloudroutine18:01:41

and dependencies that often aren't involved in the compilation process at all

cloudroutine18:01:07

like FSharp.Formatting and FAKE

juhoteperi18:01:25

So two groups can have different versions of a dependency, but I'm not sure when or how groups are used. Can one use both versions in one program?

juhoteperi18:01:58

Or well, that's probably not necessary anyway.

cloudroutine18:01:36

there's no way to fully escape from a project style system in F# since the compiler needs that to do proper type resolution and constraint analysis

juhoteperi18:01:36

In JVM it's not possible to remove stuff from classpath once they have been added there, so Boot tasks don't usually depend on anything and instead load their dependencies into pods. This way task dependencies don't leak into project classpath.

juhoteperi18:01:54

Looks like groups allow having separate dependency graph for build dependencies so there is no the same problem with Paket.

cloudroutine19:01:51

yea i had no idea this was such an issue in jvm land

cloudroutine19:01:46

rust takes the total opposite approach, just give us all the source and we'll recompile everything

cloudroutine19:01:18

which doesn't seem sustainable long term

juhoteperi19:01:25

Well all Clojure and ClojureScript libraries are distributed in sourcecode

cloudroutine19:01:07

can't escape those .jars though 😄

juhoteperi19:01:59

But that doesn't help at all if one library has breaking changes and some parts require the new version and some old

juhoteperi19:01:52

But at least it prevents Scala like dependency hell where libs have to compiled to every Scala version

micha19:01:13

i never have dependency hell problems in jvmland

cloudroutine19:01:19

ugh Scala.... X_X

micha19:01:27

because we at least have a stable, immutable dependency graph

micha19:01:53

but with nodejs and ruby i'm always getting broken builds when some new version of a transitive dep comes out

cloudroutine19:01:17

it's miserable

juhoteperi19:01:37

The Scala's problems are not caused by JVM.

cloudroutine19:01:27

they're primarily of it's own making

cloudroutine19:01:20

it's an odd type system

juhoteperi19:01:21

When 2.10 came out we had to wait like 4 months before Slick was updated for it 😄

juhoteperi19:01:04

And Slick library is maintained by Typesafe.

cloudroutine19:01:49

it's hard to put a lot of faith in them based on prior decisions

cloudroutine19:01:59

but at least they seem to be improving

jaen19:01:30

Well, they want to unify subtyping with parametric polymorphism, which IIRC is ugly even from the theoretical standpoint, so not surprising they have problems : V

cloudroutine19:01:12

as Simon Peyton Jones likes to put it, they're stuck in the swamp

jaen19:01:55

Yeah, most of my knowledge regarding that comes from https://www.youtube.com/watch?v=6COvD8oynmI P ;

jaen19:01:28

That's dependently typed, right?

cloudroutine19:01:51

but with a lot less fussing than idris

jaen19:01:49

I'm always like "whoa you can type quicksort such that it will verify it sorts" but then I'm like "that's way over my head" and I just kinda made a stop at Clojure on my road to Haskell and beyond ; d

cloudroutine19:01:38

i wish ClojureCLR wasn't so terrible 😞

alandipert19:01:28

what's bad about it?

cloudroutine19:01:54

slow, buggy, and not well supported

alandipert19:01:29

sounds full of potential

cloudroutine19:01:42

it'd actually be a lot simpler to implement the clojure compiler in F# than the C# approach they took using the Dynamic Language Runtime

cloudroutine19:01:57

it's my 2nd favorite LISP after sweet-racket

jaen19:01:35

Oooh, that looks pretty nice

cloudroutine19:01:31

homoiconic without the cruft 😉

donmullen19:01:26

@cloudroutine: as you are looking at build tools - I have never heard of this until today : https://buckbuild.com/ - Facebook’s tool - supports multiple languages / ios / android. One of the cljs + native mobile guys is looking at using it.

donmullen19:01:20

Some potentially interesting ideas there for boot - but assume all you #C053K90BR devs have seen it before.

cloudroutine19:01:11

which ideas do you find the most interesting?

donmullen20:01:06

They have worked hard on speed - don’t like that it is declarative - where boot embraces code. Lots of caching - first order dependencies. Some sophisticated stuff for mobile like Android Dex merging. Haven’t looked in depth yet - but some mobile devs are looking closer.

donmullen20:01:08

Seems like a boot-buck task would be interesting add for mobile dev.

micha20:01:37

facebook knows which buttons to press when releasing open source software

micha20:01:56

facebook rule #1: must have perf announcement

micha20:01:18

it's the problem you didn't even know you had, solved!

micha20:01:16

imagine how much more perf we'd have if we added anouther 10x of boilerplate and spaghetti code!

micha20:01:28

it's so fast your baseball cap turns backwards

donmullen20:01:49

Yeah - well we are using gradle a good bit @ LGS - VERY SLOW. This blog indicates much faster builds : http://zserge.com/blog/buck-build-system.html

donmullen20:01:19

Especially for native - where there is not as much active live reload going on - makes a big difference.

micha20:01:38

boot does extensive caching of immutable things

micha20:01:49

like uberjar stuff etc

donmullen20:01:57

Absolutely not thinking buck would replace boot - to be clear.

micha20:01:01

so you can build a massive uberjar in < 2s

micha20:01:46

i guess they just push my buttons, those facebook guys simple_smile

donmullen20:01:06

😡 😈

magomimmo22:01:46

hi all, I just published the 20th tutorial of the modern-cljs series. It guides step by step in publishing a library to clojars by using boot: https://github.com/magomimmo/modern-cljs/blob/master/doc/second-edition/tutorial-20.md

chromalchemy23:01:36

I have a webdav folder I uploading hoplon web pages to. Boot seems to update file-date(modified) on most of the files and folders in the target folder. Even unchanged image files! I guess re-copying most of the fileset. How can I upload and merge only files that were explicitly changed since last time? My upload time, with all the updated .html-out folders and updated assests is 20 min each push!

chromalchemy23:01:46

I am using the target task, and tried with and without BOOT_EMIT_TARGET=no , and (task-options! target {:no-clean 'true})

chromalchemy23:01:49

I have my static assets under :resource-paths. Is that an issue? I seem to remember having a problem using :asset-paths

chromalchemy23:01:05

I'm on Win 8.1 and things seem to be working fine otherwise!

chromalchemy23:01:07

Should I use BOOT_EMIT_TARGET=no in the general case ....?

micha23:01:51

@chromalchemy: yes i think you should

micha23:01:07

also the target task shouldn't be molesting modification times

micha23:01:22

i'll see if i can reproduce this behavior

micha23:01:52

in fact the target task shouldn't be writing anything if nothing changed

micha23:01:05

you can enable debug output with boot -v ...

micha23:01:32

it will show you when files are being copied, hardlinked or "touched"

richiardiandrea23:01:28

is there a way to have optional options or default values to boot tasks?

micha23:01:51

@richiardiandrea: you can use task-options!

micha23:01:03

to set default options

micha23:01:07

is that what you mean?

micha23:01:15

@magomimmo: that's awesome!

magomimmo23:01:08

@micha: thanks! boot is kind of joy to work with!

richiardiandrea23:01:14

@magomimmo: I searched for task-options! but it looks it is not in the tutorial

micha23:01:58

haha @richiardiandrea i'm reading the task options section right now

micha23:01:22

it's in there

richiardiandrea23:01:28

lol great, I just tried a classic CTRL-F4

richiardiandrea23:01:37

@micha I must be blind but can you point me to where it talks about optional task options? 😖

micha23:01:52

how do you mean "optional"?

richiardiandrea23:01:02

Sorry, optional or with a default value, like in a task for git fetching that I am working on I pass the url but the branch I want it to be optional, if not there, it defaults to master

micha23:01:32

ah, i misunderstood your question before

micha23:01:59

there isn't any affordace for that in the deftask options dsl

micha23:01:08

but you can easily do like this:

micha23:01:51

(deftask foo
  [b branch NAME str "The git branch."]
  (let [branch (or branch "master")
    ...

richiardiandrea23:01:24

ok great, yes it is what I am doing 😄

magomimmo23:01:29

yes! I wrote exactly that in the tutorial

richiardiandrea23:01:09

ok guys thanks to both!