Fork me on GitHub
#boot
<
2016-06-17
>
berrysoup13:06:03

Hi, how to get boot version within build.boot? I thought about BOOT_VERSION but is that variable set if user did not set it up before?

berrysoup13:06:41

I think I found solution. I will freeze boot version by setting up boot.properties file

berrysoup13:06:57

not ideal but ....

alandipert13:06:37

I know there is a var in boot.core, unsure of name. Perhaps boot-version

alandipert13:06:03

*boot-version* that is

alandipert13:06:57

Setting version with boot.properties is a good thing usually though

berrysoup14:06:32

that does not work: (pod/with-eval-in @(create-pod) (require '[clojure.pprint :as pp] '[boot.core :refer :all]) (pp/pprint (get-env)))

micha14:06:01

@berrysoup: that's right, pods are completely isolated clojure runtimes

micha14:06:32

the stuff in boot.core, like set-env! and fileset and so on are not available in pods, but you can get the pod's jvm environment via boot.pod/env var

micha14:06:57

that works in any pod and is similar to (boot.core/get-env), returns the same thing

micha14:06:14

the boot.pod namespace is accessible in any pod

micha14:06:18

shows which parts of the boot API are available in pods

berrysoup14:06:23

@micha: So I have no access to +variable+ within boot file anyway.

micha14:06:58

how do you mean?

micha14:06:17

what is +variable+?

berrysoup14:06:36

@micha: sorry I meant (def +version+ "0.1.3.1") +version+ .

berrysoup14:06:46

@micha: thanks a lot. I found boot.pod/get-classpath and I found that pod was built correct 🙂

micha14:06:10

things like the fileset and set-env! are only available in the core pod

micha14:06:25

because they are a facade over global shared state

micha14:06:32

like the filesystem for instance

meowy17:06:50

In a Boot script, how can I wait for background threads?

meowy17:06:03

It seems to be eagerly exiting once all forms have been evaluated in the script.

meowy17:06:15

Problem is, I'm trying to run an Immutant server.

meowy17:06:20

Seems like the good old (.join (Thread/currentThread)) trick works. :P

meowy17:06:42

Deadlocking the main thread with itself, basically.

micha17:06:15

@meowy: there is a wait task

micha17:06:19

which you can use for that

micha17:06:31

like boot repl -s wait

meowy17:06:41

Yeah, but I'm using a Boot script.

micha17:06:54

ah, yeah so you want something like @(promise)

micha17:06:01

that will just block forever

meowy17:06:14

That's another way that works.

meowy17:06:09

A promise that's never delivered. It's like a metaphor...

micha17:06:59

Zen Master: What is the result of @(promise)

meowy17:06:09

Incidentally, it's a Turing test.

meowy17:06:46

A weirder question, is there any way to make Boot consider new snapshot versions of deps in a script?

meowy17:06:49

I noticed that lein deploy adds a lot of nifty stuff as snapshot version, and I figure that this could be useful to avoid having to update the version of my (private) dep in my boot script every time I run it.

micha17:06:14

how do you mean?

micha17:06:09

you want to get the latest artifact, including snapshots?

micha17:06:40

(set-env! :dependencies '[my/thinger "(0,)"]) will do the trick

micha17:06:28

(using version ranges in dependencies of a library you distribute via Maven is greatly frowned upon, but for an application it's fine)

meowy17:06:20

Hmm. Trying that, but it doesn't seem to pull the latest dependency for some reason. Specifying the version of it manually does work, however.

micha17:06:42

oh i forgot a layer of vector in there

meowy17:06:52

Yeah, I fixed that. Still doesn't work, strangely enough.

meowy17:06:02

0.1.0-20160617.165455-1 is the old version, 0.1.0-20160617.171241-2 is the new version.

meowy17:06:40

I'm just using this for hobby projects, mind, I'm not that lazy about versioning real projects.

micha17:06:56

it could have something to do with your local .m2 cache

micha17:06:04

snapshots are cached for some amount of time

micha17:06:16

and i don't think it's an exact science with that lol

micha17:06:30

snapshots in maven act strangely

meowy17:06:05

The odd thing is, the new version of the dep is already in my Maven cache because I already manually referred to it.

meowy17:06:49

I'll just clear the cache and deploy a new version, let's see if that works.

micha17:06:06

you could try BOOT_LOCAL_REPO

micha17:06:14

and have a separate maven repo for your application

micha17:06:22

so it doesn't get confused

meowy18:06:47

Actually, I found a solution.

meowy18:06:58

You can use :update :always in your repo entry:

meowy18:06:14

(set-env! :repositories [["localhost" {:url "" :update :always}]])

micha18:06:35

haha booplesnoot excellent

meowy18:06:51

I couldn't come up with a name. \o/

meowy18:06:01

And, hey, my website's https://pounc.es/ ...

micha18:06:30

haha 👍

meowy18:06:10

Thanks for your help, micha!

meowy18:06:07

Also, @micha, you need to remove thinkminimo [dot] com from your projects' pages on GitHub...

micha18:06:28

hm, that's from like 2009

micha18:06:36

where did you see it

meowy18:06:20

Yeah, it's been parked and now does malicious redirects.

meowy18:06:56

That's just the first redirect, JS on the page will redirect you further to possibly malicious content.

meowy18:06:49

And the "Allow" thing refers to desktop notifications, oddly enough.

meowy18:06:10

Turns out, this is a new malvertising strategy...

meowy18:06:08

Turns out that Chrome supports push notifications now, which work just like smartphone push notifications work.

meowy18:06:23

Yep. And if you are a naive user and click "Allow", then you're subscribed to what I presume to be malicious push notifications. It's pretty much like adware that doesn't need to be installed...

meowy18:06:15

Possibly more projects.

micha18:06:22

weird i don't remember doing that

micha18:06:28

i will get rid of those

micha18:06:40

thanks for the heads up 🙂

meowy18:06:39

No problem. I also contacted Aimtell about this.

meowy18:06:58

In chat, no less. Startup support's nice, you can talk to the devs. :P