Fork me on GitHub
#boot
<
2016-06-02
>
bendy07:06:35

How does one package a cljs library and publish it to clojars with boot? Clj applications make sense - make a jar, publish that - but I can’t seem to find any good info on the cljs equivalent

bendy07:06:45

I’m trying to port an existing lein project to boot, and everythings working great, I just need to swap out lein release 🙂

martinklepsch07:06:41

deploying clojure or clojurescript to clojars is the same process

martinklepsch07:06:50

build a jar, upload to clojars

bendy07:06:47

well that’s easy then!

bendy07:06:21

I guess in hindsight, that makes sense, since it’s a java ultimately compiles cljs

bendy09:06:59

another question - is it possible to write a fileset from a task without using target?

bendy09:06:37

for example, I’m trying to write codox documentation to a top level directory (outside of the build)

bendy09:06:10

if I run boot codox target -d “codox” I get all of my resources copied over, as well as the generated codox code

bendy09:06:46

Ideally I’d like to just take the fileset commited by boot codox and write that to a new directory

martinklepsch09:06:03

@bendy: You can use the sift task to filter stuff from the fileset, take a look at the include & invert options

bendy10:06:44

hmmm… that’s helpful, but doesn’t quite solve the issue

bendy10:06:27

I could output all the files to a single directory, then sift out that directory, but then I’d be left with something like codox/docs/*

bendy10:06:56

where I’m trying to get codox/*

martinklepsch10:06:03

(sift :move ...) 🙂

bendy10:06:16

haha, touche. that’s awesome, thanks

pesterhazy10:06:55

what cljs (with reloading, ideally also repl) templates do people recommend?

martinklepsch10:06:51

uhm, tenzing? 😛

pesterhazy11:06:33

works like a charm

dm316:06:49

how about this kind of thing:

boot.user=> (macroexpand '(pipeline (bump-version :rel-ver "1.1.1") (comp (pom :classifier "rpc") (jar))))
(boot.parallel/runcommands :commands ["bump-version --rel-ver 1.1.1" "pom --classifier rpc -- jar"] :batches 1)

richiardiandrea16:06:24

if yo want to parallelize I would count the number of "commands" and then set :batches accordingly

richiardiandrea16:06:54

but it looks an awesome addition to boot.parallel

dm317:06:24

yeah, not sure what's the proper way to add this

dm317:06:48

certainly nicer to write forms when calling from code

richiardiandrea17:06:13

oh man, I have been craving for this for long time 😉

richiardiandrea17:06:08

I think also that you can extract the "transforming" functionality and add it to boot.core or boot.utils depending on what Micha likes more

anmonteiro17:06:41

Does anyone know of a particular reason why c.t.n/refresh doesn’t work in the boot.user namespace?

anmonteiro17:06:47

it seems to work in other NSes

dm317:06:56

what do you mean by "doesn't work"?

dm317:06:01

what happens?

martinklepsch18:06:21

@richiardiandrea: re you comment on the pods page: If you could pass tasks a "fake env" that is constant that would also solve your problem no? You said a few times "task execution" time but from what I read task creation time is fine — you just want to avoid changing the user's env.

martinklepsch18:06:25

Does that sound right?

richiardiandrea18:06:10

yes well, all the tasks at the moment are using get-env (and modify it if necessary)

richiardiandrea18:06:23

for fetching deps

richiardiandrea18:06:41

but in my case I don't have the set of deps until the task is executed

richiardiandrea18:06:04

because a user can pass a flavor, e.g. boot dev -f frontend

martinklepsch18:06:04

but this is task creation time, not execution time? creation = (build); runtime = ((build) fileset) if that makes sense

richiardiandrea18:06:48

yes sorry it is creation time

richiardiandrea18:06:24

and in fact I do a set-env! at creation time to set the deps

martinklepsch18:06:02

yeah, so with that in mind env/deps could be a constant, ie. there's no need for a function that returns deps based on the time the task is run at or whatever

micha18:06:55

it's pretty crucial that you don't do that, too

richiardiandrea18:06:00

just want to avoid overriding the "global" classpath

richiardiandrea18:06:08

I know, it is a workaround

micha18:06:17

or you get nondeterministic behavior with tasks that may run your task more than once or repeatedly

richiardiandrea18:06:41

it does not bother me too much because set-env! is called twice in the dev task only atm

micha18:06:00

basically the state used by the task when it runs should come from the fileset only

richiardiandrea18:06:07

but I know it is bad 😈

micha18:06:26

because the fileset is immutable and reversible etc

martinklepsch18:06:48

is env part of the fileset?

richiardiandrea18:06:57

so meta on the fileset?

micha18:06:04

no, that's global mutable state

micha18:06:15

there is no way to revert a change to the env

martinklepsch18:06:26

> basically the state used by the task when it runs should come from the fileset only so that's not really true right? — err misread, at run time it is

micha18:06:41

well other than read-only things

richiardiandrea18:06:29

so basically the convention we need to change is: don't take the env from get-env but from the fileset somehow?

martinklepsch18:06:05

@richiardiandrea: just wondering, in the case of lambone, if you had edn files that describe frontend/backend deps wouldn't that help?

richiardiandrea18:06:38

mmm...well the problem is not where they come from but how boot-cljs reads them

micha18:06:44

the env is global, so there isn't a need to pass it with the fileset

richiardiandrea18:06:48

at the moment it uses get-env

martinklepsch18:06:01

ah yeah, right... 😄

micha18:06:02

but it shouldn't be modified by tasks while the pipeline is running

richiardiandrea18:06:33

so we should find a way to read them from somewhere else

richiardiandrea18:06:41

maybe a task option

micha18:06:44

you can read them from boot.pod/env

richiardiandrea18:06:58

I see it is a convention problem

richiardiandrea18:06:03

not implementation

micha18:06:42

i guess i need to study the examples

micha18:06:47

the example use cases

richiardiandrea18:06:53

so the previous task needs to populate boot.pod/env and boot-cljs reads from it

micha18:06:07

boot.pod/env is managed by boot

micha18:06:32

it has the same info as (get-env) but is available in any pod

martinklepsch18:06:17

@micha let me try to summarize: it would be nice to shadow the global env to better separate multiple apps running in the same boot pipeline. This shadowing is only needed at task creation time, not run time.

micha18:06:47

i agree there, it's "complecting" two different concerns the way it is set up now

micha18:06:02

like tasks use the global env as the initial env for new pods

micha18:06:11

we want a new thing perhaps

micha18:06:17

a dynamic binding

micha18:06:42

like boot.pod/*env* or something

martinklepsch18:06:05

would that affect get-env?

micha18:06:07

that would also help enforce the "initialize pods at task creation time"

micha18:06:18

it would default to get-env perhaps

micha18:06:25

but you could rebind it

richiardiandrea18:06:26

no yes, it is shadowing so it should not touch get-env

richiardiandrea18:06:39

agree with the above

micha18:06:00

boot would do like (binding [*env* (get-env)] (build pipeline here...))

martinklepsch18:06:02

@micha and tasks should use boot.pod/*env* instead of get-env in that case y?

micha18:06:30

yep, they can make a lexical binding if they construct the pod asynchronously

micha18:06:47

(deftask foo []
  (let [pod-env *env* ...

micha18:06:10

because the *env* won't be bound when the pipeline runs

micha18:06:15

only when it's constructed

micha18:06:39

or i guess we don't even need to expose it explicitly

micha18:06:54

the make-pod function could use whatever the *env* binding is

micha18:06:29

ah nm, that was nonsense

martinklepsch18:06:36

I like the explicitness of (make-pod (get-env) ...)

micha18:06:44

yeah agree

micha18:06:11

so you'd do (let [pod-env *env*] ... (make-pod pod-env ...))

martinklepsch18:06:03

This could be a big deal. I'm still running 4 JVMs occasionally because I have to run 4 services locally for dev.

micha18:06:19

holy cow lol

richiardiandrea18:06:35

I specifically tried to avoid this in lambone

martinklepsch18:06:42

#C0LT8HJ67 lol

richiardiandrea18:06:59

boot can do it !

martinklepsch18:06:48

I gotta run but someone should put this stuff somewhere 😄

martinklepsch18:06:04

(open an issue probably)

juhoteperi18:06:27

@martinklepsch: In some cases I run mock services using Component inside the main system

juhoteperi18:06:51

A system itself is a component so it is easy to embed systems inside systems

juhoteperi18:06:29

Obviously this works only if the dependencies are shared etc. so they can be run inside the same classpath

anmonteiro19:06:39

@dm3: doesn’t work after changing x:

boot.user> cc/x
2
boot.user> (repl/refresh)
:reloading (my-ns.core)
:ok
boot.user> cc/x
2
boot.user> 

martinklepsch20:06:06

@micha @richiardiandrea ^

anmonteiro21:06:48

is it possible to start boot-cljs-repl/cljs-repl only as server?

anmonteiro21:06:45

looking at the boot-cljs-repl source, what I might want to do is to just create the repl-env

anmonteiro21:06:05

and then connect to it manually. But I’m unsure where I should do it

juhoteperi21:06:08

@anmonteiro: What are using repl with?

juhoteperi21:06:24

You can pass repl-env to for example Vim-fireplace

anmonteiro21:06:01

I’m using emacs / CIDER

anmonteiro21:06:37

I wanna be able to switch between CLJ/CLJS REPLs in the CIDER REPL buffer

anmonteiro21:06:48

I’m not sure if this is possible though

juhoteperi21:06:48

Have you tried the example in readme?

anmonteiro21:06:26

my use case is a bit different

anmonteiro21:06:58

@juhoteperi: let me try to explain: I have a CLJ REPL started by cider-jack-in In it, I run a boot task that compiles my CLJS (and I store it in a future)

anmonteiro21:06:18

I wanna be able to start a CLJS REPL that connects to that compiled CLJS

anmonteiro21:06:31

and close it when I want to go back and edit CLJ code

anmonteiro21:06:20

I’m not sure if this is possible at all. Maybe I should start by seeing if it’s possible to connect to the nREPL server started by the boot-cljs-repl task

micha22:06:59

it starts just the nREPL server

micha22:06:29

you access the "brepl" by connecting to the nREPL server and evaluating (start-repl)

micha22:06:02

not sure how cider handles that, but without cider just starting the server is the default behavior

anmonteiro22:06:11

@micha: got it, so I probably still need a way to change REPL connections

juhoteperi22:06:45

I believe you can connect to nrepl started by Boot and use that same connection for both clj and cljs

juhoteperi22:06:21

cider-connect maybe?

anmonteiro22:06:34

@juhoteperi: I can definitely do that, but that would mean I need a terminal where I run the boot command

anmonteiro22:06:46

in a perfect world I can just do cider-jack-in

juhoteperi22:06:03

Having a terminal seems much better to me 🙂

juhoteperi22:06:10

Maybe some Emacs users have better tips

anmonteiro22:06:51

I’ve never needed a terminal to develop Clojure after I started using Emacs