Fork me on GitHub
#boot
<
2016-10-05
>
richiardiandrea00:10:00

@anmonteiro I know that conch accepts an :env key but let me check what dosh does

richiardiandrea00:10:05

you can try if it works

richiardiandrea00:10:14

I see the args are passed as is

anmonteiro00:10:20

@richiardiandrea interesting, I didn’t know about conch

anmonteiro00:10:38

I solved it another way but I think it wouldn’t work anyways

richiardiandrea00:10:43

yeah that's awesome, boot includes it

anmonteiro00:10:48

because of (assert (every? string? args))

richiardiandrea00:10:02

yes env vars should be strings

anmonteiro00:10:14

yeah, but :env wouldn’t 😄

richiardiandrea00:10:00

so you should definitely check conch 😉

naomarik05:10:07

is there a way to hook into bootcljs's warn so I can put failed clojure.specs there?

naomarik05:10:40

and see it pop up in mah browsar?

dominicm08:10:36

@naomarik Yes. Check the code path I showed you yesterday. It's not officially supported, but I think there's potential there to extend what boot-reload can do.

mikebelanger12:10:16

hey guys anyone upgrade to latest os x (sierra)? Break anything?

mikebelanger12:10:59

*has anyone upgraded to latest os x?

manenko12:10:14

everything works fine for me

mikebelanger12:10:09

cool — sorry I realize I should’ve asked this on #off-topic

micha14:10:33

@mikebelanger it's on topic here if it breaks boot 🙂

adamfrey14:10:38

does anyone know of an existing boot task for creating a node CLJS repl instead of a browser CLJS repl?

mikebelanger14:10:15

@micha true! Hopefully it hasn’t done that touches wood

mikebelanger14:10:53

Can someone help me with extracting a particular file from a JAR? I’m looking at the :add-jar option in sift, and its asking for a the project symbol to plug into a map with a corresponding regex.

mikebelanger14:10:55

...Do I get this project symbol by requiring it in? I’ve tried this, but it can’t find it. Or what’s the basic process to get a JAR’s symbol name?

micha14:10:38

@mikebelanger is the JAR from a maven dependency?

micha14:10:59

that's what the :add-jar is doing

micha15:10:16

so for example, suppose you want to add the clojure jar to your fileset. you'd do that with :add-jar {'org.clojure/clojure #".*"}

micha15:10:55

the key in the map is the maven group-id and artifact-id, where group-id is the symbol's namespace and artifact-id is the symbol name

mikebelanger15:10:03

@micha yeah, well its in my local maven repo, it’s not on the server-based one, if that makes a difference.

mikebelanger15:10:20

@micha So basically I can grab any jar by plugging the name with the above symbol notation?

micha15:10:54

@mikebelanger yep, although it may not actually fetch the jar from maven if it's not already in the cache

micha15:10:10

that seems like something we'd want to fix

micha15:10:34

can you create a github issue for that, if it doesn't automatically fetch the jar?

mikebelanger15:10:27

@micha by cache, do you mean a local machine’s ~/.m2 directory?

micha15:10:50

@mikebelanger exactly

mikebelanger15:10:53

@micha I’d be willing to open an issue, sure. But I want to make sure I understand, first. I’m developing some externs with cljsjs, and those externs are already in a jar in my cache, in the cljsjs (group-id?). These externs aren’t on clojars, or cljsjs yet, because I’m still working on them.

mikebelanger15:10:54

@micha Are you saying boot may not :add-jar something that’s not already in the cache, but on somewhere like cljsjs/clojars?

micha16:10:08

@mikebelanger no, the opposite: :add-jar expects the JAR to be in the local .m2 cache. If it's not :add-jar may not fetch it from clojars

micha16:10:33

hm sorry, i think we just both said the same thing

mikebelanger16:10:13

@micha sorry I threw a lot of negatives in my last sentence, its all good

mikebelanger16:10:16

@micha thanks - I appreciate the heads up on this (potential) limitation. For what I’m doing now, it shouldn’t be an issue — everything is on the local m2 cache. But this is good to keep in mind for future projects. I plan to use boot quite a bit 🙂

micha17:10:33

@mikebelanger i just tested it, with :add-jar for a jar not in ~/.m2 cache, and it throws an exception 🙂 so this is a thing that will go on the list of things to do

yury.solovyov17:10:42

What's the current blessed way of using npm with boot?

mikebelanger18:10:42

@micha cool thanks for testing 🙂

mikebelanger18:10:02

@micha I guess for now, a workaround would be moving that jar into ~/.m2? That’s how I’ve been asking people to play with my project 😛

micha18:10:48

@mikebelanger yes you can do a local install: boot install -f foo-1.2.3.jar -p pom.xml

micha18:10:49

that will install the jar foo-1.2.3.jar into your local ~/.m2, with the coordinates defined in pom.xml

mikebelanger18:10:48

@micha oh cool, I had no idea boot could do that!

mikebelanger18:10:56

@micha to be honest, I’m having much more basic problems with boot. If I’m not mistaken, the :to-resource command is meant to move a file from the Fileset into the designated resource directory. The same directory that you assign in the (set-env! :resource-paths)?

dominicm18:10:21

@mikebelanger It's supposed to make it look like it came from there, I think

dominicm18:10:27

Your inputs get split, and then tasks read the relevant parts. Sometimes you need to shift them around, pretend something existed before it did, etc. This is my understanding at least.

dominicm18:10:59

You should never output to resources. Unless you're doing code generation as a one-off I guess.

mikebelanger18:10:28

@dominicm woa, ok I had a completely different understanding of what resources meant in that context.

mikebelanger18:10:45

@dominicm I have these two files that are considered resources. They’re asm-compiled js files, and they have to be in the final target directory.

mikebelanger18:10:29

@dominicm I never need to recompile the files, or really modify them. I just have to ensure the boot package downloads the correct version, and md5 it for consistency.

dominicm18:10:54

I think they should just appear. But that's where @micha knows much better than me.

mikebelanger18:10:34

@dominicm how would you recommend I ensure that I move two files over from the project in the maven repo into the target directory? Preferably automatically.

micha19:10:31

@mikebelanger the :to-resource is just changing the "roles" of the files

micha19:10:07

the actual filesystem directories in which the files are stored is an implementation detail that doesn't really matter for your purposes

micha19:10:15

the convention is for tasks that create new files add them to the fileset as resource

micha19:10:37

because a file created by a task can be the input to another task, and also files creaetd by tasks are likely to be artifacts you want to include in packaging

mikebelanger19:10:31

@micha oh, see I thought resource files were anything that didn’t need compilation, and could be used for input/and or output. I assumed the Fileset is meant for encapsulating any file, whether another task created it or not.

mikebelanger19:10:40

@micha what would be the recommended way of ensuring some files are always in the output directory? Just a project template?

micha20:10:35

@mikebelanger you're correct about the fileset, it's for encapsulating any file, as you say

mikebelanger20:10:06

@micha Yeah I’ve been reading that. Hmm I guess I’ll have to read more. Thanks to you both for your time and help!

micha20:10:50

@mikebelanger the target task is what writes files to the target dir

micha20:10:59

we can look at the source:

micha20:10:13

hm that isn't as illuminating as i thought it would be

micha20:10:25

it has some fanciness for performance

micha20:10:42

but here is a simplified version of the target task:

seancorfield20:10:27

Has anyone tried using the built-in Socket REPL with a Boot process?

seancorfield20:10:59

I’ve been playing around with it this morning and realized that if you run anything in a pod, it’ll fail — the main Clojure runtime that starts to run Boot will start the Socket REPL and then the instance inside the pod will also see the -Dclojure.server.* property and try to start a Socket REPL… which blows up with Address already in use.

seancorfield20:10:07

Trying to figure out a good workaround for it.

micha20:10:11

(deftask target
  [d dir PATH str "The target directory"]
  (with-pass-thru fs
    (let [in-files (->> fileset (output-files))]
      (doseq [tmp in-files]
        (let [infile  (tmp-file tmp)
              path    (tmp-path tmp)
              outfile (io/file dir path)]
          (io/make-parents outfile)
          (io/copy infile outfile))))))

micha20:10:51

@seancorfield sure, you just don't want to start it via system properties

micha20:10:03

you can start it via clojure function

seancorfield20:10:22

But then it’s not automatically handled by the Clojure runtime...

micha20:10:01

that's the current recommendation

seancorfield20:10:30

Ah, so it’s a known issue. That’s good, at least. Will read the recommendation...

micha20:10:44

system properties are JVM global

micha20:10:54

although one trick is to unset it

micha20:10:10

ah that won't work

micha20:10:17

there are already 2 pods before your code runs

micha20:10:54

i want to start using socket repl instead of nrepl

micha20:10:59

see if that's possible

micha20:10:45

@mikebelanger the code i pasted above is a simpler target task

micha20:10:11

the thing to notice is

(let [in-files (->> fileset (output-files))]

micha20:10:36

that gets all the "output" files

micha20:10:44

those are the ones that will end up in the target dir

micha20:10:17

those will be TmpFile objects

micha20:10:29

the next few lines loop over those and copy them to the target dir

micha20:10:55

so to finally answer your question: the way to ensure that things get into the target dir is to make sure they are "output" files

micha20:10:38

files in the fileset that were added as resource or asset will have the "output" role

micha20:10:49

that's where the wiki page might help

micha20:10:08

it has a little table that shows which roles are associated with which name

seancorfield20:10:25

The problem with that workaround is you actually have to program something into every application you write. The whole point of the Socket REPL is to be able to start a REPL under control of the environment, for any Clojure process.

micha20:10:50

that means you can only have one clojure runtime though

micha20:10:59

so if you make an uberjar and you don't have pods you can do that

micha20:10:19

there is no way to have multiple clojure runtimes all binding to the same port

seancorfield20:10:21

Yeah, which basically completely rules out using Boot to drive processes in any production environment where you want that external control. Unless you specifically add logic to every process to work off some other non-standard control… That’s a shame...

micha20:10:40

i'd put it in the build.boot

micha20:10:01

it could read an ENV var or a different system property

micha20:10:18

i don't think you lose anything there

micha20:10:01

(if-let [port (System/getenv "REPL_PORT")]
  (repl ...

micha20:10:04

or whatever

micha20:10:38

you could do fancier things with boot-shim.clj

micha20:10:04

you could select which pod to launch repl in, or launch a repl in each pod on different ports

seancorfield20:10:04

Hmm, interesting… so it would still be external to the actual code but would still need to be programmed into the build file… I’ll have to give that some thought. We are moving to an uberjar-based workflow but we have a lot of Boot-powered stuff right now...

micha20:10:12

yeah i mostly use uberjars too

micha20:10:42

when we were using docker it was more attractive to use boot as the entrypoint

micha20:10:53

but we're not using docker much anymore in production

micha20:10:15

so now it's uberjar + upstart

seancorfield20:10:11

We’re currently re-evaluating our use of REPLs across multiple tiers. Today our code explicitly starts (and stops) a REPL in each app where we thought we’d want one — and we actually use a full CIDER-enabled nREPL server — but we want to get away from that, based on measuring how we actually use those REPLs. We like having a rich REPL in DEV (of course) but we don’t want to run those elsewhere and, in general, we don’t want to run a REPL at all by default.

micha20:10:01

yeah we run the socket repl but haven't needed it yet

micha20:10:26

we engineer the applications so we can take a node out of service whenever we want

micha20:10:37

so attaching to a running process isn't so important then

seancorfield21:10:13

We like the option to be able to do live debugging from time to time (and very occasionally live patching on a few processes).

alandipert21:10:02

i'm attracted to the idea of running a repl for collecting metrics

alandipert21:10:30

like in theory it's a way to get metrics out of apps that we didn't anticipate the need to log or datadog

seancorfield21:10:06

But based on our actual historical usage of the REPLs we have been running, we can probably step down to using a bare bones REPL for some of them, and just stop doing it altogether for others.

mikebelanger21:10:50

@micha so the asset/resource files are added to output-files list whenever the (sift :to-resource... is used, I see.

micha21:10:13

precisely ^^

mikebelanger21:10:37

@micha thanks for the code-walkthrough, and yeah I’ve been going by this part https://github.com/boot-clj/boot/wiki/Filesets#fileset-components