Fork me on GitHub
#boot
<
2016-05-31
>
dominicm15:05:03

@micha: https://github.com/adzerk-oss/boot-cljs/pull/119 can I CC you on this? You know a little more about boot's "big plans" for it.

dominicm15:05:53

@martinklepsch: I really appreciate your input. ❤️

micha16:05:00

i think we should follow the protocol of using the env at task construction time for pods that will be spawned later

martinklepsch16:05:34

@micha I think that's a very reasonable default but I think it's also a hindering constraint when creating more complex setups (edge/lambone)

richiardiandrea16:05:44

Yeah sometimes you really want to specify deps at task runtime..I remember the need

micha16:05:19

yeah we want a dynamic var or something like that

micha16:05:47

need to engineer it though because things can happen asynchronously

micha16:05:09

so we'd need to establish the correct treatment for that type of situation

richiardiandrea16:05:02

And I remember I read Deraen solution and thought it would be nice if pods had "settable" dependencies

micha16:05:42

just use add-dependencies in the pod

richiardiandrea16:05:45

Yes well if it's going to be a dynamic var it is already thread bound

micha16:05:00

well i don't think we need to support every permutation

micha16:05:07

that's how we get spaghetti

martinklepsch16:05:14

@richiardiandrea: when you say at runtime, do you really mean at runtime or more like "different than the main env"

micha16:05:16

we need to properly separate the concerns

richiardiandrea16:05:14

But I need to fetch an example first s that it is clear what I am talking about

richiardiandrea16:05:53

And I am on mobile now so cannot really do it, I will just follow the discussion ;)

martinklepsch16:05:00

maybe @richiardiandrea and @dominicm can make a wiki page with the kind of things they found lacking and then that can be used to come up with a solution?

juhoteperi18:05:17

Yeah, and some descriptions of use cases where separate frontend / backend dependencies are needed could be helpful

dominicm18:05:43

@juhoteperi: The ability to have different core.async libs is neat (or any other cljc project). Also, not "polluting" your java project with sub-dependencies of the clojurescript libraries is nice. It's a bit of a "purist" view on isolation from each other.

juhoteperi19:05:16

Well the apps I build are so tied together that there is no really isolation between backend and frontend

juhoteperi19:05:40

Different core.async versions sound bad as there might be some code which uses core.async and is used on both back and front

juhoteperi19:05:20

So the descriptions of use cases are necessary for me to understand what you want to do, otherwise I'll presume other people build same kind of apps as I do 😄

dominicm20:05:13

@juhoteperi: More than fair 😛. I think it's useful to have control over what is both, and what is either. > Different core.async versions sound bad as there might be some code which uses core.async and is used on both back and front Without being overly specific: You may not have time to upgrade frontend / something is breaking in your hacks from an older version / etc.

dominicm20:05:22

It's more defensive programming in my mindset, than a strong solution. Boot makes that kind of isolation fairly easy to achieve so it seems like a perfect match 🙂

richiardiandrea22:05:55

Agree and Lambone (following edge) tries to separate f/b but still keep the same JVM...the result is great I think (of course). The biggest limitation was that I could not inject my own custom deps in tasks like cljs because they are creating pods at task creation time

richiardiandrea22:05:25

So I have to call set-env! at my task creation time

richiardiandrea22:05:38

It would be great if I could just pass my deps to the task and cljs would then pass them to the pod without fetching them from get-env

richiardiandrea22:05:15

I hope is clear, I can paste a code sample