Fork me on GitHub
#boot
<
2016-07-27
>
devn00:07:11

EXIT, STAGE LEFT

micha01:07:22

@devn almost forgot

pesterhazy07:07:29

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

torgeir12:07:21

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

alandipert13:07:24

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

anmonteiro16:07:25

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

anmonteiro16:07:30

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

anmonteiro16:07:15

maybe, I’ll try

anmonteiro16:07:31

yeah, just works

anmonteiro16:07:40

much more flexible than Lein, awesome

oahner16:07:22

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

micha16:07:36

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

oahner16:07:27

so ./ is required even on windows

micha16:07:32

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

oahner16:07:05

I figured as much from boot.main/shebang?

oahner16:07:12

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

micha16:07:12

yeah it's tricky

oahner16:07:15

the ./ did the trick

micha16:07:17

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

micha16:07:26

like registering a handler somehow?

oahner16:07:50

without cygwin or some other unix machinery? I doubt it

oahner16:07:14

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

micha16:07:22

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

micha16:07:22

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

oahner16:07:41

oh, file extensions, that's a bit ugly

oahner16:07:48

altho it would technically work

oahner16:07:49

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

oahner16:07:11

./executable syntax doesn't exist on windows

oahner16:07:20

only boot executable.boot can work

micha16:07:31

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

micha16:07:40

or delete a file

micha16:07:47

it needs to be deterministic

oahner16:07:09

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

oahner16:07:40

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

micha16:07:55

how about maybe exposing the launch4j stuff in boot itself?

micha16:07:01

or as a task

micha16:07:09

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

micha16:07:25

or a boot task

micha16:07:34

boot script foop

oahner16:07:48

that would certainly be a nice feature

oahner17:07:23

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

oahner17:07:53

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

oahner17:07:00

one folder per script

oahner17:07:17

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

micha17:07:42

yeah .boot extension would be similar to that

micha17:07:52

or whatever extension you prefer

micha17:07:12

probably the cleanest solution, given the various constraints

oahner17:07:19

technically

oahner17:07:24

unless I'm missing some detail

micha17:07:48

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

micha17:07:02

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

oahner17:07:11

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

micha17:07:16

and the shebang parsing is different on different unix machines

micha17:07:35

but what if it's a python file for instance

micha17:07:43

with #!/bin/python or whatever

oahner17:07:57

that would mean someone ran boot.exe file.py

oahner17:07:11

it wouldn't happen

oahner17:07:38

when the file runs, the executable is already found

oahner17:07:42

there's no shebang on windows

micha17:07:46

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

oahner17:07:53

*no shebang support for scripts

micha17:07:56

or if there are multiple slashes

micha17:07:23

yeah i think we could do that, what you propose

micha17:07:35

it hurts my brain to think about it though lol

oahner17:07:44

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

oahner17:07:16

there's no way that could be ambiguous

oahner17:07:21

forgot one thing

micha17:07:26

guile scheme has a clever system:

micha17:07:48

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

micha17:07:53

or maybe it does?

oahner17:07:11

it... doesn't

micha17:07:23

that's the money right there

micha17:07:59

we could still do it i guess

micha17:07:49

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

micha17:07:51

or something

oahner17:07:33

that wouldn't solve the problem for windows tho

oahner17:07:47

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

micha17:07:31

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

oahner17:07:32

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

micha17:07:34

because of the dot

oahner17:07:42

yes, that could work

oahner17:07:51

files rarely don't have an extension on windows

micha17:07:21

ok yeah this seems sane to me

oahner17:07:50

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

oahner17:07:01

that would be a good UX for a windows dev

micha17:07:21

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

oahner17:07:03

add a flag?

micha17:07:11

that's a valid symbol

oahner17:07:12

boot -f file.boot

micha17:07:24

yeah we could add a flag

oahner17:07:24

or whichever letter is available

micha17:07:40

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

micha17:07:23

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.

micha17:07:31

those are the ones we currently have

oahner17:07:59

I'd be tempted to say x for eXecute

micha17:07:19

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

oahner17:07:32

oh, then -x for that

richiardiandrea17:07:23

yeah about the option, there is an issue open

richiardiandrea17:07:09

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

micha17:07:13

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

micha17:07:36

we could do them both at the same time

oahner17:07:17

that would be #465?

richiardiandrea17:07:12

uhm, thought I opened one

oahner17:07:02

that bot is quick

oahner17:07:32

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

richiardiandrea17:07:25

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

oahner17:07:00

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

richiardiandrea17:07:28

great that's awesome

oahner17:07:47

altho now I have a completely unrelated problem

oahner17:07:57

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

oahner17:07:02

guess what the shebang breaks

oahner17:07:34

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

oahner17:07:44

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

oahner17:07:15

that appears to be a yes

micha17:07:40

@oahner: only in the core pod though

richiardiandrea17:07:19

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

dave17:07:19

@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

micha17:07:56

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

micha17:07:00

it's pretty gross

oahner17:07:21

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

oahner17:07:47

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

micha17:07:49

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

micha17:07:09

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

micha17:07:21

like the fileset stuff, and so on

micha17:07:41

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

micha17:07:06

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

micha17:07:33

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

micha17:07:46

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

oahner17:07:01

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

micha17:07:17

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

micha17:07:41

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

oahner17:07:09

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'

oahner17:07:27

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

oahner17:07:48

looking good!

micha17:07:52

yeah that's fine

micha17:07:13

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

micha17:07:40

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

micha17:07:49

but any namespace in the core pod is fine

oahner17:07:30

I'll have to read up on pods

micha17:07:00

pods are just isolated clojure runtimes

micha17:07:16

they can have different classpaths, different clojure versions, etc

oahner17:07:30

definitely overkill for my use-case

micha17:07:52

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

micha17:07:18

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

oahner17:07:01

I can see that being useful for build scripts alright

oahner17:07:31

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

oahner17:07:40

it's great!

micha18:07:43

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

micha18:07:06

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

micha18:07:18

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

micha18:07:24

because you do it at runtime

micha18:07:31

so that can be slow

alandipert18:07:13

hehe yes, hooks

alandipert18:07:18

The Marke of The LifeCycle

dominicm18:07:20

hooks break cursive 😞

dominicm18:07:09

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

richiardiandrea19:07:40

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

micha19:07:35

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

micha19:07:02

and with pods, forget about it

richiardiandrea19:07:20

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

lmergen20:07:14

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

micha20:07:44

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

micha20:07:30

we didn't see any reliability issues with it

oahner20:07:07

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

micha20:07:11

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

oahner20:07:06

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

lmergen20:07:48

right, that makes sense.

lmergen20:07:47

i hadn't considered that boot uses so much ram

lmergen20:07:48

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

micha20:07:17

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

micha20:07:26

that's sometimes a huge time saver

micha20:07:41

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

micha20:07:47

you can throw it in a pod

lmergen20:07:02

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.

martinklepsch20:07:15

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

borkdude20:07:18

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

bsima20:07:09

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

bsima20:07:21

if that's what you mean...

lmergen20:07:03

hmm that wouldnt be included in the jar ?

micha20:07:07

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

borkdude20:07:31

I'll check that out, thanks

micha20:07:32

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

micha20:07:39

but i think you can remove that

micha20:07:46

actually i'll try it right now

micha20:07:55

and let you know if it actually works 🙂

oahner20:07:15

@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

oahner20:07:32

it works great with immutant

micha20:07:38

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

micha20:07:22

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

micha20:07:17

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

micha20:07:36

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

richiardiandrea20:07:01

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

richiardiandrea20:07:33

pretty straightforward I guess

borkdude20:07:51

@micha thanks, -C worked for me