Fork me on GitHub
#boot
<
2015-08-12
>
onetom00:08:32

@catonano: hi! i just sent u a pull request which shows how to use the semantic ui cljsjs package. i will document it in the readme; thanks for pointing it out!

juhoteperi15:08:01

@micha: I'm thinking boot/pod should use MrAnderson for external libraries

micha16:08:14

that thing looks extremely fishy

juhoteperi16:08:15

@micha: So that we don't need to copy paste the files and it's easy to keep the deps up to date

micha16:08:31

oh, for its own deps?

juhoteperi16:08:04

also makes the licensing clearer

micha16:08:07

i think most of those can be in the worker pod

juhoteperi16:08:30

hmm which one is the worker pod?

micha16:08:40

the worker/ subdir

micha16:08:52

you use it via with-eval-worker etc

juhoteperi16:08:00

I'm not sure

juhoteperi16:08:07

I think most of them are used currently directly

micha16:08:32

i saw what mranderson did in refactor-nrepl

micha16:08:43

it seems like something we want to stay far away from

micha16:08:18

if you think it's good we can try it

micha16:08:29

don't mind my prejudice

juhoteperi16:08:48

I'll investigate using worker pod first

juhoteperi16:08:55

Eval could cause problems in some cases

juhoteperi16:08:44

But I think in version-clj case pod overhead shouldn't matter and the with-eval-worker could be hidden behind boot api

micha16:08:05

yeah that's the idea already

micha16:08:16

a lot of stuff in boot.core is done in the worker alraedy

juhoteperi16:08:30

But I think some of stuff on boot.from.* currently wouldn't work

micha16:08:36

i was going to add version-clj to worker to solve that problem

micha16:08:12

yeah some things need to be local

micha16:08:30

we also had to modify some of them

micha16:08:54

i don't think we even need to keep up to date with versions really

micha16:08:06

the things in boot.from are used for specific purposes

juhoteperi16:08:20

Looks like backtick has had some bug fixes again

micha16:08:33

yeah backtick could go in worker

juhoteperi16:08:44

Hmm I doubt that

micha16:08:45

any macros really

micha16:08:49

sure, why not?

micha16:08:26

the ~ might be tricky but i think doable

juhoteperi16:08:07

Becaue with-eval-worker uses backtick

micha16:08:32

we want (.invoke worker-pod ...) to do it

micha16:08:44

but yeah if mranderson can generate boot.from namespaces then maybe we should use it

juhoteperi16:08:34

Unfortunately it generates random names instead

juhoteperi16:08:54

We could convert boot pod project to Boot and write own task to include dependency files? 😄

micha16:08:28

i've been meaning to do this for a while, we should!

juhoteperi16:08:29

Though it's the namespace renaming which is hard part

juhoteperi16:08:43

But we could probably make that unnecessary

micha16:08:53

yeah that part gives me the heebie jeebies

juhoteperi16:08:21

if we don't have to rewrite all namespaces reffering those libs it's easy

micha16:08:40

we dont, sot that's good

micha16:08:53

only the internal references

micha16:08:58

but then you have transitive deps

micha16:08:04

which are the new problem

micha16:08:13

like if we rewrite dep A and dep B

micha16:08:18

and A references B

micha16:08:49

still doable i suppose

micha16:08:09

could be a boot task for it

juhoteperi16:08:57

Maybe it's easiest to keep boot.from as is and add version-clj to worker pod

micha16:08:08

that would definitely work

juhoteperi16:08:20

I didn't know about worker-pod so I was thinking version-clj should be added to boot.from

micha16:08:30

i put all the things in worker pod

micha16:08:39

like the crypto stuff, etc

micha16:08:45

works great

micha16:08:05

then make a shim in the boot/core project that uses with-eval-worker

juhoteperi16:08:21

Great solution to keeping existinb boot.from stuff up to date would be a bash script 😄

micha16:08:24

or boot/pod project probably

micha16:08:54

i think all the things in worker pod have shims in boot/pod

micha16:08:01

which is accessible in all pods

micha16:08:10

including, interestingly, the worker pod itself

micha16:08:27

there is logic to detect when with-eval-worker is called from the worker pod itself

micha16:08:32

and it does the right thing

micha17:08:29

looks like using old boot version

micha17:08:45

before 2.0.0 where we introduced tmp-* things

micha17:08:04

before that it was core/tmppath

alandipert18:08:03

i think something weirder is happening, because those old ones should still work

alandipert18:08:20

it looks like it’s using an older versino of boot-cljs than specified in build.boot, one that has core/tmppath in the source

alandipert18:08:42

in any case it must be something other than the build.boot such as profile or boot version, because i can’t reproduce

micha18:08:50

i mean if you're using a boot task that calls boot.core/tmp-path with pre-2.0.0 boot version you'll get that error

micha18:08:12

because while tmppath existed in those older versions, tmp-path did not

micha18:08:40

we need to have boot show -d show more dependency scopes, perhaps?