https://www.youtube.com/watch?v=D2OBLzm-lSw

EXIT, STAGE LEFT

@devn almost forgot

@micha, thanks for the pointer, I'll check that out

Yo! Was playing around with using this for compiling my protobuf files, and it seems it needs the protobuf.jar on boot’s classpath to have javac complete the compilation without errors - whats the correct way to add a .jar to boot’s classpath? I have the protobuf.jar laying around in the same folder as my .proto files, the same folder from which I’m running boot https://github.com/aJchemist/boot-protobuf

@torgeir: the boot.pod/add-classpath function will do it

is it possible to run a .clj file with boot, analogous to lein run -m clojure.main script.clj?

just found this https://github.com/boot-clj/boot/wiki/Boot-for-Leiningen-Users#lein-run

but what if my script doesn’t have a NS declaration?

@anmonteiro: load-file maybe?

maybe, I’ll try

yeah, just works

much more flexible than Lein, awesome

is there a way to call a boot script without it having a shebang? say, on windows?

@oahner: if you put #!/usr/bin/env boot at the top of the file, say myscript.boot, you can then do boot ./myscript.boot

oh!

so ./ is required even on windows

got it

the shebang is used internally in boot so it knows thedifference between myscript the script and myscript the task name

I figured as much from boot.main/shebang?

but I couldn't get it to even find the file

yeah it's tricky

the ./ did the trick

i think there is a way to have real shebang support on windows though

like registering a handler somehow?

without cygwin or some other unix machinery? I doubt it

I had gotten it to work in sh with just ./script.boot, but from cmd.exe, no such luck

hm i thought i saw something back when we were designing the shebang stuff

https://docs.python.org/3/faq/windows.html#how-do-i-make-python-scripts-executable

now i remember, the python guys figured something out i think

oh, file extensions, that's a bit ugly

altho it would technically work

wouldn't it be possible to ignore the shebang on windows and assume it's a script if the argument is a file?

./executable syntax doesn't exist on windows

only boot executable.boot can work

then you end up with unexpected behavior when you create a file with the same name as a task

etc

or delete a file

hmm

it needs to be deterministic

then, how about, verify that there's a valid shebang, but don't look it up on the filesystem

aka make "#!/usr/bin/env boot" work even if the env executable isn't there

how about maybe exposing the launch4j stuff in boot itself?

or as a task

so you can use boot to turn your script into an exe

or a boot task

boot script foop

that would certainly be a nice feature

actually

my ideal workflow is starting with a repl, coding a something.boot, then when I'm satisfied with it from the repl, have a way to run it from the command line

up until now I've been keeping scripts as folders with a build.boot in it

one folder per script

whereas in python I'd have one folder with a lot of one off .py files in it

yeah .boot extension would be similar to that

or whatever extension you prefer

probably the cleanest solution, given the various constraints

technically

unless I'm missing some detail

making the shebang machinery in boot smarter is problematic because there are different limitations on unix platforms

like some platforms support arguments to the shebang interpreter and some do not

modifying boot.main/shebang? to return true if a) platform is win32 and b) file starts with #! would solve this (on windows)

and the shebang parsing is different on different unix machines

but what if it's a python file for instance

with #!/bin/python or whatever

that would mean someone ran boot.exe file.py

it wouldn't happen

hm yeah

when the file runs, the executable is already found

there's no shebang on windows

also another interesting thing is that the last segment of the path, if it contains a dot then it can't be a task

*no shebang support for scripts

or if there are multiple slashes

yeah i think we could do that, what you propose

in fact

it hurts my brain to think about it though lol

for portability's sake, I would simply look for #!/usr/bin/env boot

there's no way that could be ambiguous

hmm

forgot one thing

guile scheme has a clever system:

https://www.gnu.org/software/guile/manual/html_node/Running-Guile-Scripts.html

cygwin

alas, clojure doesn't support the multiline comment syntax like that

or maybe it does?

it... doesn't

https://www.gnu.org/software/guile/manual/html_node/The-Meta-Switch.html#The-Meta-Switch

that's the money right there

we could still do it i guess

#!/usr/bin/env boot \
;; -e main -s
#!

or something

that wouldn't solve the problem for windows tho

#!/usr/bin/env boot would still not resolve on the filesystem

so if the file has an extension then it's not ambiguous

but if someone is in cygwin, then they're on windows, but shebang machinery is available

because of the dot

yes, that could work

files rarely don't have an extension on windows

ok yeah this seems sane to me

if windows, if arg1 exists on the filesystem, if arg1 endswith .boot, execute it

that would be a good UX for a windows dev

i was thinking that if arg1 isn't a valid symbol we could look for it as a script

hmm

why not

add a flag?

oh dang

that's a valid symbol

boot -f file.boot

my bad

yeah we could add a flag

or whichever letter is available

that's the best thing to start with, cause that would be handy anyway

nice

OPTS:    -a --asset-paths PATH       Add PATH to set of asset directories.
         -b --boot-script            Print generated boot script for debugging.
         -B --no-boot-script         Ignore boot script in current directory.
         -c --checkouts SYM:VER      Add checkout dependency (eg. -c foo/bar:1.2.3).
         -C --no-colors              Remove ANSI escape codes from printed output.
         -d --dependencies SYM:VER   Add dependency to project (eg. -d foo/bar:1.2.3).
         -e --set-env KEY=VAL        Add KEY => VAL to project env map.
         -h --help                   Print basic usage and help info.
         -o --offline                Don't attempt to access remote repositories.
         -P --no-profile             Skip loading of profile.boot script.
         -r --resource-paths PATH    Add PATH to set of resource directories.
         -q --quiet                  Suppress output from boot itself.
         -s --source-paths PATH      Add PATH to set of source directories.
         -t --target-path PATH       Set the target directory to PATH.
         -T --no-target              This option is ignored.
         -u --update                 Update boot to latest release version.
         -U --update-snapshot        Update boot to latest snapshot version.
         -v --verbose                More error info (-vv more verbose, etc.)
         -V --version                Print boot version info.

those are the ones we currently have

I'd be tempted to say x for eXecute

hmm

yeah and we also want an option you can pass a string to eval

i think

oh, then -x for that

yeah about the option, there is an issue open

I haven't started working on it yet though, but it would solve a cider issue as well

sweet, @oahner maybe add your option to that ticket too?

we could do them both at the same time

that would be #465?

checking

uhm, thought I opened one

https://github.com/boot-clj/boot/issues/465

yes

that bot is quick

actually

if you implement the first part of this ticket (execute arbitrary forms), then loading a file is just one load-file away

yes true that

I'll try my best, I have been very busy lately

no worries, I believe I have a viable workaround for the time being 🙂

great that's awesome

altho now I have a completely unrelated problem

rofl

in vim-fireplace, the namespace is taken from the first line

guess what the shebang breaks

all my code gets evaled in 'user instead of 'boot.user

I suppose set-env! and friends can be required from any namespace?

that appears to be a yes

@oahner: only in the core pod though

hmm

well if you have boot.core on the class path I think you can right Micha?

@micha how does the boot shebang line #!/usr/bin/env boot work? i assumed it was like running boot /path/to/file.boot, but when i run that command, it says that /path/to/file.boot isn't a task

@dave yeah it's convoluted, there are a lot of edge cases that need to be handled with clever hacks

it's pretty gross

I take it that means "the line works" but "the environment might not be right"?

(use 'boot.core) does work from the user namespace

well the boot "env" is the jvm environment for the core pod

this pod is special in that there is a lot more machinery at work to make it sane

like the fileset stuff, and so on

this machinery is needed because you need a mutable place in which to bootstrap yourself

but when you create pods you have a lot more control over the environment when you construct the pod

so you don't need to change things from inside the pod, you can just construct it the way you want it to begin with

the core pod isn't like that because boot neds to create it for you before your code can run

that appears to be outside the scope of my use case, thankfully ^^'

so tldr; the core pod set-env! and friends are not thread-safe

and not intended to be used in other pods, so definitely not tested for that use case

for now I can eval stuff in script.boot via vim-fireplace by doing (use 'boot.core) and then running that file later on with 'boot ./script.boot'

the extraneous (use 'boot.core) doesn't seem to break anything when we're already in boot.user instead of user

looking good!

yeah that's fine

you can do (use 'boot.core) in any namespace

it's only when you're evaluating expressions in other pods that you might not be able to do that

but any namespace in the core pod is fine

I'll have to read up on pods

pods are just isolated clojure runtimes

they can have different classpaths, different clojure versions, etc

ahh

definitely overkill for my use-case

yeah it's useful when you're making build tasks, so you can isolate your task's dependencies frorm the project

you load your tasks dependencies in a pod and do work in the pod

oh right

I can see that being useful for build scripts alright

how is it that boot loads up so much faster than lein?

it's great!

i think it depends on what you're doing, sometimes it's faster, sometimes it's slower

there are some optimizations boot can't do because of the dynamicness

like it can't know which dependencies you wil want to load in advance

because you do it at runtime

so that can be slow

reason number 328 to use boot: https://github.com/technomancy/leiningen/blob/2.6.1/src/leiningen/test.clj#L76

hehe yes, hooks

The Marke of The LifeCycle

hooks break cursive 😞

and test.check, it seems https://www.bountysource.com/issues/36003731-leiningen-test-hooks-clash-with-test-check-0-9-0

Yeah, hooks break a fair few things, quite a rabbit hole of issues you can go down.

Oh that's good I am not using lein ...that sounds like my issue with tools.reader some time ago...classpath clashes all the way coming from I-do-not-remember-which dependency

i work on nodejs stuff at work a lot, and man, maven is way easier to debug than npm for me

and with pods, forget about it

yeah pods don't even compare to anything out there, so that's the edge we have 🙂

so, i heard about something that i consider unconventional, that people use boot to launch their applications in production as well. at first i thought that was crazy, but it actually makes a lot of sense -- it brings your production and build environment closer together, and brings a lot of easy flexibility. do people do this a lot ? i don't see a lot of examples of people using boot to handle their production environment as well

@lmergen: we did it a lot when we were deploying to docker containers, but recently have been just making uberjars

we didn't see any reliability issues with it

@lmergen: did that for a whole week until my server ran low on ram, switched to wildfly and wars

with docker you can easily bake all the maven dependencies into the image

it's nice being able to just drop a jar in a folder and let the application server just reload it

right, that makes sense.

i hadn't considered that boot uses so much ram

perhaps it would be nice to be able to bake certain parts of boot into your app

one thing that is nice about using boot as the entry point for the application is that you can use pods in your application

that's sometimes a huge time saver

like if you need some hairy dependency that causes problems with the rest of your app

you can throw it in a pod

one thing that i would really want is to define my production main function as a task right within my build.boot, just like you define all other tasks.

@oahner: does wildfly help with things that are not HTTP services? (e.g. what's called a worker in Procfiles)

@micha re: color of output in REPL - if it's REPL-y, why don't I see it in lein repl? still wondering

@lmergen: you can just do (defn -main [& args] ...) righn in your build.boot

if that's what you mean...

hmm that wouldnt be included in the jar ?

@borkdude: i wonder if it's the aviso nrepl middleware?

https://github.com/boot-clj/boot/blob/master/boot/pod/src/boot/repl.clj#L12

I'll check that out, thanks

@borkdude: sorry, i think i've developed a mental block against the nrepl stuff

but i think you can remove that

actually i'll try it right now

and let you know if it actually works 🙂

@martinklepsch: I haven't actually had a need for long running background services yet, but technically it just runs your jar's entry point and manages its lifecycle, it should work the same for non-HTTP processes

it works great with immutant

@borkdude: no luck

@borkdude: the best workaround i can think of at the moment is boot -C repl

https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj#L384-L390

that's where the repl task is figuring out the options to pass to the REPLy nREPL client

reply has a :color option, as you can see there

we could add an option to the repl task to let you override that

@lmergen: thanks to Danielsz, I added that in lambone 😉 https://github.com/Lambda-X/lambone/blob/master/resources/leiningen/new/lambone/common/dev/boot.clj#L104

ignore the <% part ..it is the selmer template

pretty straightforward I guess

@micha thanks, -C worked for me