Fork me on GitHub
#boot
<
2016-01-26
>
richiardiandrea00:01:20

also @micha, is adding meta to TmpFile as simple as with-meta ?

micha00:01:05

actually you can just assoc

micha00:01:28

that's how the --add-meta thing works

micha00:01:57

beacuse it's not really metadata to the program, it's metadata from the user's perspective

richiardiandrea00:01:06

yes I was actually checking that in boot.core

micha00:01:13

but that metadata should still be considered in equality tests for instance

micha00:01:26

i mean the fileset metadata added by the user

richiardiandrea00:01:37

you also dissoc [:dir :path :id and :time]

micha00:01:55

those are the fields of the TmpFile record type

micha00:01:22

hm, we added a couple of fields i think

richiardiandrea00:01:30

yes, I might actually just call boot.core/add-meta that does the right thing 😄

micha00:01:40

haha :+1:

richiardiandrea00:01:22

last thing @micha, how can I explode a fileset in its java.io.Files?

richiardiandrea00:01:36

because add-meta needs filepaths

richiardiandrea00:01:55

can I just take :tree ?

micha00:01:27

the java.io.Files?

micha00:01:51

i don't think anything cares about the file paths, only the relative paths in the fileset

micha00:01:55

the :path

micha00:01:36

also the keys of the :tree map

richiardiandrea00:01:48

but about the file inside the fileset...is :tree what is needed for the TmpFiles ?

micha00:01:32

thank you!

richiardiandrea00:01:45

(I need this to work asap ahahah!)

bensu00:01:11

is there any template like tenzing but with a backend? (ideally saapas as a template)

donmullen00:01:08

@bensu: don’t know of one - but with boot new coming from @seancorfield - perhaps we can get one put together. What stack would you start with? Same as saapas?

bensu00:01:37

@donmullen: thanks. saapas would be nice

bensu00:01:03

if it doesn't exist, in the future I'll probably make saapas into a template

seancorfield01:01:33

I’d be thrilled to see a something/boot-template up on Clojars as something to point to for others!

richiardiandrea01:01:25

Soooo @micha sorry to bother again, but is the following correct:

:tree
 {"replumb/boot_cljs_src.clj"
  {:dir
   #object[java.io.File 0x5dff50b "~/mylongdir/boot-cljs-src/cwn/-x24pa9"],
   :bdir
   #object[java.io.File 0x73faa25d "~/mylongdir/boot-cljs-src/cwn/-7kd6cy"],
   :path "replumb/boot_cljs_src.clj",
   :id "13a18d07a582fd99407bf48fa488f89b.1453772310000",
   :hash "13a18d07a582fd99407bf48fa488f89b",
   :time 1453772310000,
   :boot-cljs-src-tag true}, <- added metadata
  ....  

micha01:01:38

that looks right

micha01:01:49

the value should be a record, right?

micha01:01:54

of type TmpFile

richiardiandrea01:01:27

yes......but with-meta returns nil because it looks like it checks (meta x) (in https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task_helpers.clj#L63)

micha01:01:08

ah that could be the issue, right?

richiardiandrea01:01:07

I can fix that, it should be a normal get, I will try, but I will break things 😄

micha01:01:22

hahaa :+1:

richiardiandrea02:01:15

sooo, I investigated what is passed inside sift-meta and it looks like it is just a string, which is the file path, no TmpFile instance...

micha02:01:54

boot ... sift --with-meta foo

micha02:01:37

that should remove all paths (and associated TmpFiles) from the fileset that don't have the following condition:

micha02:01:20

(contains? (get-in fileset [% :foo]))

micha02:01:28

where % is the path

richiardiandrea02:01:45

is passing just k not the rest (`:dir ...`)

richiardiandrea02:01:54

you can confirm it by printing inside sift-meta

richiardiandrea02:01:08

(defn- sift-meta
  [invert? kws]
  (->> (map #(fn [x] (do (clojure.pprint/pprint x)
                        (contains? (meta x) %))) kws)
       (apply some-fn)
       (comp (if invert? not identity))))

micha02:01:09

yeah that doesn't look like it's going to work

richiardiandrea02:01:12

so I will change sift-filter and the other fns...shouldn't be that hard to keep the same behavior

richiardiandrea02:01:26

sift-match can accept k and v where v is a TmpFile

micha02:01:40

sweet, sounds great

richiardiandrea02:01:11

sorry match? but ok it should work

jethroksy02:01:30

@jaen: are you using the ecs-cli? I'm trying to follow your panda5 example, but ecs-cli is actually so limited... it doesn't support build

jaen09:01:33

@jethroksy: I've used AWS before, but not from the CLI. And that university project was only deployed on Heroku, then Openshift and then Digital Ocean, though I don't think deployment on EC2 would be all that different from DO.

jethroksy09:01:38

ah... I think i'm gonna end up using just a raw EC2 instance

jaen09:01:14

Yeah, that'd be the easiest, I think.

jaen09:01:42

Or you can create a docker image, put it in a repo and then create a scaling group with run configurations pulling that image and running that.

jaen09:01:02

Done it with a Ruby deployment before, it worked quite okay.

jaen09:01:39

The downside is your app has to be stateless, so you should do things like uploading files to S3 and such.

jaen09:01:17

If I've linked you to this - https://gitlab.com/jaen/panda5 - instead of the github repo (I don't remember) then this has docker image creation, so the only part left would be to figure out the scaling groups thing.

jaen09:01:17

Though it might be an overkill for just a simple app.

martinklepsch10:01:02

Let's say boot-http wants to expose the port it choose randomly to other tasks in the pipeline: what is the best way to do this? I'm thinking of adding a file to the fileset but also technically it's possible to just (assoc fileset :http-port p) - other options?

codebeige10:01:50

I found the following quote there: > It's also possible to assoc directly onto the fileset object itself for project-level metadata, if desired.

codebeige10:01:42

As the boot-http task will also serve files that are created downstream, I see no real relation to TmpFiles here.

codebeige10:01:31

So this is why I would consider it "project-level metadata"

martinklepsch10:01:34

I haven't seen code doing this before but given the discussion there probably its fine. Sorry for the confusion then I guess :) @codebeige

codebeige10:01:14

I was also looking for any examples before, could not find one, either.

codebeige10:01:09

So it is not really "best practice" yet.

martinklepsch10:01:47

One problem I could see is in the context of a watch task that creates new filesets which might drop this data (there is some merging done there not sure if outside of :tree as well)

martinklepsch10:01:02

In any case probably good for now :)

martinklepsch10:01:03

One thing I noticed: when using a threading macro non-forms will automatically wrapped in parens so you don't have to do that.

codebeige10:01:53

Yes, this is true. I tend to keep them around, if there also a form that takes options and has parens. I like the alignment better. But this is purely personal taste.

ijmo11:01:03

Hello! Anyone using emacs flycheck with boot repl? It works fine with lein repl.

alandipert11:01:20

anyone using boot to do electron stuff w/ cljs?

alandipert11:01:44

i'm curious in general to know what the state of boot/node/cljs is

martinklepsch12:01:34

@alandipert: I did some electron stuff — anything in particular you'd like to know?

martinklepsch12:01:18

fairly straightforward really

martinklepsch13:01:17

@juhoteperi: just stumbled upon this: https://github.com/jafingerhut/dolly — might be handy for the namespace importing in boot

pandeiro13:01:16

I'm doing some housecleaning with boot-http PR's and I'm wondering if anyone has any opinions re: these - https://github.com/pandeiro/boot-http/pull/32 & https://github.com/pandeiro/boot-http/pull/35

pandeiro13:01:22

Both use-cases are things that I had previously considered solvable by just writing a custom handler, which has always been supported by boot-http

pandeiro13:01:44

BTW @codebeige thanks for your PR's; I'll merge those as soon as I decide what to do with these two ^

martinklepsch13:01:27

@pandeiro: maybe instead of adding options the README could list these scenarios with fitting handlers? They both seem useful but also add bloat that might be better solved with documentation.

pandeiro13:01:15

The README is also getting bloated @martinklepsch ! 😄

martinklepsch13:01:38

Then a "Recipes" wiki page or so?

martinklepsch13:01:00

I think what I'm saying is just adding more and more options will exponentially increase the number of combinations and people might expect them to all work seamlessly when they don't necessarily do. Helping people understand how they can write their own simple ring handlers to accomodate their needs might better for everyone

pandeiro13:01:22

Yeah I definitely see your point there.

pandeiro13:01:33

I guess I'm trying to assess how common these scenarios really are.

martinklepsch13:01:34

also testing that all things on their own work becomes a lot more work

pandeiro13:01:00

Yes for sure. Already supporting Jetty and HTTPKit means testing almost every PR in two variations at least

pandeiro13:01:06

At the same time, this lib has always tried to be somewhat of a Swiss Army Knife, solving lots of different HTTP serving use cases

pandeiro13:01:45

It would be nice if there were some way to poll the community of users in situations like this, affecting the API

pandeiro13:01:54

Is there a better way to do that than informally, here?

alandipert13:01:17

i would say PRs are votes in that case

pandeiro13:01:40

and then what are the nay votes?

pandeiro13:01:44

comments on PRs?

alandipert13:01:09

like the 404 thing... i would probably veto, because that's application behavior i'd rather have in application code than in my build.boot

alandipert13:01:37

but otoh, it seems like something a Swiss Army Chainsaw would do

martinklepsch13:01:44

@alandipert: not necessarily if they're writing a frontend that uses pushState?

alandipert13:01:09

well they shouldn't do that either simple_smile

martinklepsch13:01:25

(assuming that is out of question simple_smile )

alandipert13:01:31

but again there's plenty of room for there to be lots of libraries that do what different people want

alandipert13:01:42

or for one library to do everything, if the maintainer is up for it

martinklepsch13:01:30

@pandeiro: maybe instead of adding options to the task the lib could come with some sort of contrib namespace where people can contribute more general handlers

martinklepsch13:01:55

and then people could use these for the :handler option

pandeiro13:01:33

Wow @martinklepsch I think that is a very cool idea, pre-fab handlers one can drop in

martinklepsch13:01:02

this way the option explosion wouldn't be there at least :))

martinklepsch13:01:20

plus there is a clear path for future contributions in similar directions

donmullen13:01:11

@alandipert: @martinklepsch : tell me more about NOT using pushState for SPA front-end (static site).

martinklepsch13:01:50

@donmullen: I think the general point is that it muddies the water between the correct "entry point" into an application from an HTTP perspective. I draw most of that observation from conversations with @micha btw

donmullen13:01:03

To serve up and support links into the static site — is there a better way?

pandeiro14:01:57

if you handle all requests through a generic handler that serves the app and place the routing logic inside the app itself (but parsing URL paths instead of hash fragments), there's no need for pushState, is there?

pandeiro14:01:57

As I understand it, the main objective here is just getting rid of the leading #/ portion of the app's routes?

micha14:01:11

uri fragments!

donmullen14:01:49

@micha: I’m having a dejavu.

donmullen14:01:24

@pandeiro: the thought was not to use #/ - and yes handle the routing client side

donmullen14:01:20

@micha for hoplon SPAs - you are still recommending #/ ?

pandeiro14:01:36

Ah so what pushState accomplishes is hijacking the browser refresh to not load the index.html etc again?

pandeiro14:01:02

(while still maintaining the back button / history)

donmullen14:01:34

@pandeiro: that’s my understanding - but I know only enough to be dangerous 😉.

micha14:01:35

@donmullen: re: hoplon yeah, but the redirects looks workable too (just more complicated)

martinklepsch14:01:46

@pandeiro: why not introduce a namespace to boot-http providing a bunch of more common handlers?

martinklepsch14:01:32

@donmullen: if you're using S3 I might just do a little plug here: https://github.com/confetti-clj/confetti

micha14:01:09

one problem with hosting things on S3 is how they do redirects, like from http://example.com/foo --> http://example.com/foo/

pandeiro14:01:10

@martinklepsch: hmmm, yeah I suppose that could be done; but is there any reason to do that instead of a wiki page linking to separate projects with handlers? is it easier this way?

micha14:01:46

they use 302s and not 301s, which is apparently confusing to google's webcrawler and you supposedly get penalized

martinklepsch14:01:02

@pandeiro: just thinking bundling things up might be easier for users — mostly "discoverability" concern I guess

micha14:01:19

i made a varnish proxy that sits in front of s3 website at adzerk to address that

martinklepsch14:01:43

@micha: if you have a foo file they will redirect to /foo/?

pandeiro14:01:44

Another thing I just realized @martinklepsch is that the :handler option takes a function, but that function is not really parameterizable

pandeiro14:01:05

So some of these (like the forwarding) would need to become a handler factory

donmullen14:01:14

Thanks @martinklepsch

martinklepsch14:01:24

:handler (forward {:opts ..}) returning a handler?

pandeiro14:01:36

Yeah something like that

micha14:01:37

@martinklepsch: if you have a foo file then no, it won't redirect, but if you have a foo/index.html then it will

micha14:01:13

but on S3 you could have both, i believe, since there are no real folders

martinklepsch14:01:15

I see. Not something I've had a problem with

micha14:01:28

our SEO guy demanded action lol

dm315:01:35

what's the best way to find files matching a predicate in the fileset?

dm315:01:42

use the sift task from my task?

micha15:01:26

@dm3: (->> fileset boot.core/ls (filter pred?))

micha15:01:49

there are a number of built-in ones, in boot.core

micha15:01:55

for example:

micha15:01:49

(->> fileset core/input-files (core/by-re [#"\.txt$" #"\.sh$"]))

micha15:01:24

returns a seq of TmpFile objects whose paths end in .sh or .txt

dm315:01:15

working on a task that wraps criterium

dm315:01:21

was planning on capturing the result edn as files and then having another report task to format and print to stdout/write html into a file

dm315:01:37

what do you think @micha?

micha15:01:55

i think that's a fantastic plan

micha15:01:07

especially separating the notification part

micha15:01:25

we've been wanting to explore this with boot-test for a while, too

dm315:01:02

ok, so I managed to write into the file using the (let [t (core/tmp-dir!), f (io/file t "x")] (spit f content) (core/add-resources fs t))

dm315:01:25

should I query the tmpfile back from the fileset using the name to add metadata to it?

dm315:01:30

or is there a better way?

dm315:01:52

I see there's core/add-meta which expects a map {tmpfile metadata}

dm315:01:35

@micha how do I find the tmpfile?

micha15:01:49

sorry, one sec

micha16:01:49

@dm3: how do you mean "find the tmpfile"?

dm316:01:20

if I write to a file during the task

dm316:01:27

and want to call core/add-meta

dm316:01:54

what is the proper way to construct the argument to add-meta?

micha16:01:07

(-> fileset (add-resource tmp) (add-meta {"some/path.sh" {:foo 100 :bar 200} "some/other/path.sh" {:foo 666 :bar 777}) ...)

dm316:01:45

ok, got it

dm316:01:03

need to get the tmpdir path and create the path to my file

micha16:01:36

note that the "some/path.sh" is not the path to the actual file

micha16:01:43

it's the relative path in the fileset

micha16:01:08

none of the functions that involve filesets ever use the actual path to the real file for any purpose whatsoever

micha16:01:20

tmpfiles are essentially anonymous

dm316:01:31

hm, now I'm stuck constructing a path out of a tmpdir and a file name

micha16:01:04

the best way, cross platform, is this

dm316:01:06

how do I get the relative tmpdir path?

micha16:01:29

(.getPath ( "some" "path.sh"))

micha16:01:44

i don't understand

micha16:01:56

get the relative path from what

dm316:01:15

from the (core/tmp-dir!)

dm316:01:28

I assumed that the path to the returned file cannot be used

micha16:01:29

there is no relative path

micha16:01:49

that just returns an anonymous, boot-managed temporary directory you can use to store files

dm316:01:02

yes, but how I go from there to "some" in your example?

micha16:01:41

(let [tmp (tmp-dir!)]
  (io/file tmp "some" "path.sh")
  ...

dm316:01:05

ah, the tmpdir is the "root"

dm316:01:20

makes sense, as it takes no arguments to create

dm316:01:29

I was confused thinking it's nested

micha16:01:31

yes i'm assuming that later you do something like

micha16:01:43

(-> fileset (add-resource tmp) ...

weavejester16:01:46

I’ve been playing around with Boot, and I have a quick question about dependencies...

micha16:01:59

hi @weavejester ! fire away

weavejester16:01:24

Well, typically I want a set of dependencies for development, and a subset of those for production (such as generating an uberjar). In Leiningen I’d use the :dev profile. I’m not certain what the most idiomatic way of doing it in Boot is.

weavejester16:01:46

I can make a “dev” task, but it feels clunky, and doesn’t work well with require

micha16:01:59

the simplest way is to use scoped dependencies, i think

micha16:01:18

dev deps have :scope "test", which won't be included in uberjars by default

micha16:01:31

you can specify which scopes go into the uber if you want, too

micha16:01:42

there is an option on the task to change the default to whatever you want

weavejester16:01:01

Scopes are fixed, aren’t they? I can’t create my own scopes? Or can I?

weavejester16:01:16

“test” just doesn’t seem right if I’m not testing.

micha16:01:45

i think it's right, because in maven dev and test are complected

jaen16:01:10

Maybe put your dependencies in a map in an EDN file, read that file, merge the dependencies you want, and then use that to set-env!?

micha16:01:17

but since you're not going to be pushing your uberjar to maven as a dependency you can invent your own scopes, no problem

weavejester16:01:30

By “doesn’t seem right” I mean that it feels messy, even if it works! simple_smile

micha16:01:46

i don't see why it's messy

micha16:01:59

just replace "test" with "dev" in your mind simple_smile

micha16:01:12

because that's what maven should have called it anyway

micha16:01:30

scope test doesn't actually have much to do with actual testing in maven either

jaen16:01:41

Bonus points for being able to easily load new dependencies without killing boot (conflicts notwithstanding) in that way.

micha16:01:45

it's just a way to specify dependencies that are not to be propagated transitively

micha16:01:09

but without eliding them from the pom, because they may be useful as a reference

weavejester16:01:45

jaen: I could also put the base dependencies in their own def

jaen16:01:03

@weavejester: true, but then you lose the bonus points (the ability to add dependencies on the fly, to be clear).

weavejester16:01:10

micha: I generally don’t want them in the pom, though.

micha16:01:36

you can use the :dependencies option to the pom task to edit what goes in there

micha16:01:02

but poms for uberjars is a dicey proposition anyway

weavejester16:01:09

I guess maybe what I do is (def base-dependencies ‘[[…]]) then

weavejester16:01:41

Well, I didn’t just mean uberjars. Jars too.

micha16:01:02

yeah the only thing to watch out for is if you perform the dependency resolution in two steps you are not guaranteed to get the same dependency graph as if you resolved all dependencies together in one step

micha16:01:31

because of how aether works it's impossible to guarantee that (it's not transactional)

weavejester16:01:35

Well, I thought that for production I’d perhaps use a pod.

micha16:01:58

yeah pods get all their deps resolved when they're constructed, so that's good

micha17:01:32

also the things you'd put in :scope test are things like boot tasks

micha17:01:37

which have no transitive dependencies

micha17:01:42

so those are totally safe

micha17:01:58

they do their work in pods if they have dependencies of their own

micha17:01:14

you could use that pattern to eliminate the problem

micha17:01:23

do dev work in pods

weavejester17:01:30

So maybe I’d (def base-dependencies ‘[[…]]) and then (def dev-dependencies ‘[[…]])

micha17:01:30

to leave the production classpath pristine

weavejester17:01:56

And (set-env! :dependencies (into base-dependencies dev-dependencies))

micha17:01:09

sure, that would work

weavejester17:01:18

Then for production I’d just use base-dependencies

micha17:01:29

you could make two profile-type tasks, dev and prod or something

weavejester17:01:04

Yes, though the problem with that is require.

micha17:01:09

(deftask dev
  []
  (set-env! :dependencies (into base-dependencies dev-dependencies))
  identity)

weavejester17:01:55

(require ‘[adzerk.boot-test :refer :all]) needs to be at the top level otherwise it won’t resolve symbols at compile time.

weavejester17:01:40

So requiring tasks is a little problematic.

weavejester17:01:13

See the problem? A lot of tasks are dev dependencies.

micha17:01:20

scopes, i thnk, are the way to go there

micha17:01:28

much simpler

weavejester17:01:43

But then all my development deps find their way into my pom file.

micha17:01:51

not necessarily

weavejester17:01:52

Regardless of whether they’re actually used...

micha17:01:07

so you def your two things, dev and base deps

micha17:01:30

with dev deps :scope test

micha17:01:36

then when you make the pom you do

micha17:01:53

(task-options!
  pom {:dependencies base-dependencies}
  ...

micha17:01:05

that will ensure that the pom will only have base dependencies

micha17:01:23

and the :scope "test" will work with the uber task to make sure those deps aren't included in it

weavejester17:01:50

But I could also just use the base-dependencies in the uberjar task as well, right?

micha17:01:22

well you'd do (set-env! (into base-dependencies dev-dependencies) at the top level of your build.boot there

micha17:01:29

to avoid compilation problems

micha17:01:47

the uber task discriminates on scope

micha17:01:56

when it decides which dependencies to include

weavejester17:01:29

(set-env!
  :dependencies (into base-dependencies dev-dependencies))

(task-options!
   pom {:dependencies base-dependencies}
   uberjar {:dependencies base-dependencies})

weavejester17:01:36

That would work too, right?

micha17:01:45

there is no uberjar task, though

micha17:01:58

and the uber task does not currently support a :dependencies option

laforge4917:01:00

@micha In the role of squeaky wheel, I'm even having problems with watch on windows when using a library that contains .cljc files. What repository should I write up the issue on??? simple_smile

micha17:01:01

although it should

micha17:01:27

the uber task has :include-scope and :exclude-scope options

weavejester17:01:34

It doesn’t? Hm.

weavejester17:01:43

Perhaps a pod, then?

micha17:01:53

@laforge49: if you could open a ticket on boot-clj/boot repo that would be awesome

micha17:01:36

@weavejester: is there anything that breaks if you add :scope "test" to your dev dependencies, which won't end up in the pom?

micha17:01:08

you could also do a tricky thing, actually

micha17:01:14

lol i see a way

weavejester17:01:28

Hm, maybe not. It just feels a little messy compared to Leiningen’s profiles.

weavejester17:01:35

A tricky thing? simple_smile

micha17:01:43

(def alldeps (into basedeps devdeps)
(set-env! :dependencies alldeps)
(set-env! :dependencies (vec (set/difference (set alldeps) (set devdeps))))

micha17:01:09

removing dependencies from the env won't actually remove the jars from the classpath, that's impossible

micha17:01:03

but yeah, i think scopes are the best way

micha17:01:13

that's what the abstraction was designed for anyway

micha17:01:59

the scope is intended to be a way to discriminate between dependencies that are needed at runtime from dependencies needed when compiling or using the artifact as a consumer

micha17:01:16

which i think perfectly describes what you are trying to achieve also

micha17:01:49

so scope test here, without any pom :dependencies shenanigans is i think the correct way to configure it

micha17:01:06

most in line with the rest of the maven infrrastructure

weavejester17:01:15

That does make sense, but to my mind the way that Leiningen’s profiles work is better, because each set of dependencies and options is strictly isolated.

weavejester17:01:56

I guess profiles are the current best option in Boot, but I’ll give this some more thought.

weavejester17:01:10

I feel like there should be a better way simple_smile

micha17:01:58

if you think of something i'm all easr

weavejester21:01:03

Has anyone experimented with running a REPL in a pod before? Or using nREPL middleware to “enter" a pod?

alandipert21:01:10

@weavejester: you can use boot.core/launch-nrepl to start repl servers inside pods

alandipert21:01:28

show --list-pods will give you a list of all the pods

micha21:01:51

also the repl task has a --pod/:pod option

dm321:01:12

do you see a need in the boot.core/by-meta function which would filter TmpFiles based on the metadata?

weavejester21:01:37

Ah cool, thanks simple_smile

dm321:01:50

it kind of breaks the convention with other by-name/re filters by working on TmpFile instead of java.io.Files

micha21:01:50

metadata is pretty simple

micha21:01:15

(->> fileset output-files (filter :foo))

micha21:01:27

that would select tmpfiles with the :foo metadata

micha21:01:42

i guess it really should be

micha21:01:52

(->> fileset output-files (filter :foo) set)

micha21:01:03

because those functions usually return sets

micha21:01:49

a by-meta function wouldn't hurt though

micha21:01:02

for completeness

micha21:01:15

and people could look at it to see examples of using metadata on tmpfiles

micha21:01:25

haha so yes

weavejester21:01:15

@micha: What does it mean by the name of the pod in the :pod option?

dm321:01:29

(->> fs ls (core/by-meta [:my/meta #(= (:other/meta %) "test")]))

micha21:01:56

@weavejester: you can use boot show -l to get the pod names

micha21:01:10

usually the name is the namespace in which the make-pod function was called

micha21:01:26

but the name can be set to anything

micha21:01:58

so doing (boot (show :list-pods true)) you can see the names of the pods

micha21:01:27

you can't get a repl in the worker or aether pods

micha21:01:37

well maybe you can actually

weavejester21:01:39

Thanks, I see it. Looks like the pod name is “anonymous” if you create an anonymous pod. Could you tell me how I set the name?

micha21:01:53

(.setName the-pod "doop")

alandipert21:01:55

.setName on the pod

micha21:01:34

yeah it's anonymous if you create it from the repl because there isn't a namespace associated with it sometimes

micha21:01:52

it tries to inspect the call stack, which is weird in the repl

weavejester21:01:55

Perfect, thanks simple_smile

alandipert21:01:43

@martinklepsch: thanks for the electron pointer btw. no specific use in mind, just wanted to survey

weavejester21:01:03

Out of curiosity, does destroying a pod also kill off any threads it has? It’s in a separate classloader, right?

micha21:01:21

@weavejester: yes

weavejester21:01:51

micha: Very nice simple_smile

micha21:01:54

well it's not really possible to guarantee that all threads will be killed

micha21:01:00

but it does call shutdown-agents etc

weavejester21:01:17

Yeah. In the same JVM there are always limits.

richiardiandrea22:01:11

great! i was about to implement the above! ^

sekao22:01:56

i’m making a boot project that compiles both clojure and clojurescript in separate tasks. is there a way to make them use different :source-paths? I tried calling set-env! in each task but when I compose them into a single task this doesn’t seem to work.

raywillig23:01:55

hi group. does it make any sense to want to have my scss in a jar that could be brought in with checkout task? the idea is that I have this common css that I want to share between related projects. if it's not completely crazy, does anyone have any idea about how to make that happen?

juhoteperi23:01:41

@raywillig: Makes sense, but it requires that scss task reads imports from classpath or copies the files to a temp dir and passes that to scss compiler. Sass4clj does first.

raywillig23:01:29

oh cool. i will check this out. so I would use this i/o of boot-sass?

raywillig23:01:44

@juhoteperi: ^^

juhoteperi23:01:31

Instead of boot-sassc yes, to ensure confusion, my task is also named boot-sass.

raywillig23:01:32

haha, yes. ok i get it. sort of i guess. i suppose there aren't really many naming options when making a task to compile sass in boot