Fork me on GitHub
#boot
<
2016-08-18
>
pesterhazy08:08:46

(deftask deploy-release []
  (comp (build-jar)
        (show :fileset true)
        (push :gpg-sign false
              :repo "clojars")))

pesterhazy08:08:59

this gives me "Return code is: 401, ReasonPhrase: Unauthorized"

pesterhazy08:08:14

am I doing something wrong? I'm trying to push a non-SNAPSHOT release

pesterhazy08:08:44

on the assumption that it's a clojars problem, I've added a clojar issue: https://github.com/clojars/clojars-web/issues/555

pesterhazy09:08:28

hm I just can't push at all currently

dm310:08:03

I've just pushed to clojars

anmonteiro10:08:56

@pesterhazy: not sure if that’s the problem, but adzerk’s bootlaces uses “deploy-clojars” as the repo

anmonteiro10:08:22

oh it doesn’t matter at all, that’s just the name you give to the repository

pesterhazy11:08:55

Yeah that's what I figured

anmonteiro11:08:54

one thing you can try is not setting the env vars

anmonteiro11:08:11

and it’ll prompt you to insert the username and password in the CLI

stuarthalloway12:08:20

it seems like “what pod does this task run in” is a fundamental thing you need to understand to make advanced use of any task

stuarthalloway12:08:00

e.g., say I want to customize the classpath used by https://github.com/adzerk-oss/boot-test. How would I know how to do it?

stuarthalloway12:08:43

I don’t see a way, other than reading the code for run-tests to figure out how the pod is made

dm312:08:30

I'm trying to generate a namespace and then AOT in the same pipeline. Cannot seem to make it AOT, even though it's added to the resources

dm312:08:25

Looks pretty much like:

(deftask generate [] (with-pre-wrap fs (let [...] (-> fs (add-resource tmp) commit!))))
(comp (generate) (aot :namespace #{'my.generated-ns})
The fileset after generate contains the .clj file, I've verified

dm313:08:12

ok, this seems to be because it's the worker-pod which actually looks for namespaces in input dirs

dm313:08:43

which is initialized with directories before I add another one to fileset

pesterhazy13:08:19

@anmonteiro, your comment led me to the solution

pesterhazy13:08:39

I didn't realize that boot proper (without bootlaces) doesn't honor CLOJARS_USER

pesterhazy13:08:06

Now I'm using

(set-env! :repositories [["clojars" (cond-> {:url ""}
                                      (System/getenv "CLOJARS_USER")
                                      (merge {:username (System/getenv "CLOJARS_USER")
                                              :password (System/getenv "CLOJARS_PASS")}))]])

pesterhazy13:08:40

I wish there was at least a warning if you push without specifying a :username

pesterhazy13:08:04

Building a jar (https://github.com/mjmeintjes/boot-react-native/blob/master/build.boot), but the jar doesn't contain any of the .clj source files.

pesterhazy13:08:17

It only contains the resources

alandipert13:08:20

@pesterhazy: do you have them in source-paths?

alandipert13:08:46

if so, that would be why. try adding to :resource-paths instaed. source-paths doesn't have "output role" so is on classpath, but doesn't end up in jar

alandipert13:08:55

(it's good for e.g. java code, or .clj code you want to AOT compile)

alandipert13:08:02

(or cljs in an application)

pesterhazy13:08:21

that's ... surprising 🙂

micha13:08:12

@stuarthalloway: in any pod you can look at the boot.pod/this-pod var, which is a WeakReference pointing to the pod you're in

pesterhazy13:08:57

@alandipert, of course that fixed it 🙂

micha13:08:25

@stuarthalloway: there is also boot.pod/pod-id and boot.pod/pod-name

micha13:08:18

also boot.pod/pods, which is a WeakHashMap whose keys are all the pods that exist

micha13:08:33

if you want to find a specific pod and manipulate its classpath you can find the pod you want by iterating over the keys of boot.pod/pods and selecting the one you want by name (filter #(= "foop" (pod/pod-name %) (keys pod/pods))

micha13:08:54

then when you have a reference to the pod you can use with-eval-in to add dependencies etc

micha14:08:32

btw pods will by default have their name set as the namespace that called boot.pod/make-pod (like for instance the test pod should be named something like adzerk.boot-test or something like that)

alandipert14:08:10

iirc boot-test uses a pod pool though, so if you wanted to manipulate the environment you'd need to be constantly tracking down and running code in pods

micha14:08:33

there is the with-env approach

stuarthalloway14:08:00

@micha that is all good to know. That said, having looked at the pod api is it easy enough that I think I will just make my own pods when needed

micha14:08:02

tasks will start with the dependencies of the core pod, and add their own deps to those when they construct their pod

micha14:08:26

so you can, in theory, trick the task into having different deps

stuarthalloway14:08:40

I can also strip off the core pod deps if I want, right?

micha14:08:48

this assumes that the task binds the dependencies lexically in the construction phase

micha14:08:23

yes you should be able to

micha14:08:45

i think we need to make that a best practices thing for making tasks

stuarthalloway14:08:10

@alandipert: would there be a benefit to separating pod construction (or pod construction recipes) from tasks that use them. E.g. maybe I want a pod like (or almost like) the one in boot-test, but I don’t want to run a test

micha14:08:12

like with stateful transducers, you need to nail down your initial state in the construct phase

alandipert14:08:53

it seems like if you want to do something the task doesn't do, you need to make your own task 😄

alandipert14:08:21

i see the appeal of e.g. passing tasks the pod to use, but then you're fully responsible. since you must know that the task will still work

alandipert14:08:30

if you know that much already, may as well make your own thing that does exactly what you want

alandipert14:08:46

and since you've got pods and fileset to work with, it's usually not that hard

alandipert14:08:07

vs adding features to plugins in other build tools, where making your own plugin is a huge deal with at least hundreds of lines of code

micha14:08:53

(deftask foo
  []
  (let [env (-> boot.pod/env
                (update-in [:dependencies] ...))
        pod (future (boot.pod/make-pod env))]
    (fn [next-task]
      (fn [fileset]
        ...

micha14:08:17

in this case ^^ you can use alter-var-root to trick the task into using different deps

micha14:08:31

by altering boot.pod/env and then restoring it

micha14:08:07

(boot (with-env {:dependencies ...} (foo)) ...

micha14:08:17

that's the with-env approach

micha14:08:26

but if the task is written like this

alandipert14:08:45

looks like you could also alter-var-root adzerk.boot-test/base-pod-deps

micha14:08:20

(deftask foo
  []
  (let [env #(update-in % [:dependencies] ...)
        pod (future (boot.pod/make-pod (env boot.pod/env)))]
    (fn [next-task]
      (fn [fileset]
        ...

micha14:08:25

then that approach won't work

micha14:08:38

because the resolution of boot.pod/env is performed asynchronously

micha14:08:13

but i think the second way is an anti-pattern and we should make PRs to fix tasks that work that way

micha14:08:22

because it's certainly just an oversight

micha14:08:36

there isn't any advantage to doing it the second way

stuarthalloway14:08:08

I don’t (yet) see why I would want that kind of magic ^^ vs. just creating a pod with full control of what is in it

micha14:08:30

tasks use pools of pods too though

micha14:08:45

which are created dynamically while the pipeline runs

micha14:08:00

i guess it could take like a prototype pod perhaps

micha14:08:15

but then you might as well just have the env map

micha14:08:28

because that's all you'd really be able to do with the pod itself, is extract its env

micha14:08:32

to construct the new pods

alandipert14:08:56

i think the spirit of the env thing is moving in direction of a container for multiple apps using boot as entrypoint, not necessarily participating in any kind of build

micha14:08:00

any initialization of the prototype pod would be opaque to the task

stuarthalloway14:08:05

if I am understanding how boot-test works, it demonstrates all I need

stuarthalloway14:08:55

Just make a pod with an env you make explicitly, without touching or modifying the global env

stuarthalloway14:08:10

use the global env as a basis if you want, or not

micha14:08:30

but i can also see the need for something like with-env

micha14:08:49

like consider a case where your project has a dependency that conflicts with something a task will add to its own local pods

micha14:08:10

you might want to eliminate that problematic dependency just for that task, so its pods don't have it

micha14:08:46

like if you're making a webapp and you're running boot-test on the backend code, and maybe something in google closure compiler conflicts

micha14:08:00

you don't need google closure to test the backend, so you could remove it

micha14:08:08

but just for the test task

micha14:08:37

but the test task will still need other dependencies of your project to function correctly

micha14:08:40

like maybe ring or whatever

stuarthalloway14:08:37

I think “this” (how tasks reuse common things they might need) is orthogonal to two of the key benefits of boot: the pipeline and pods

stuarthalloway14:08:58

I might use boot for the pipeline, give tasks I author complete and explicit control of the pods they make, and never/rarely participate in the classpath aspects of the shared env

micha14:08:46

the with-env thing is to make it easier to integrate other more general tasks into your own specific pipeline when your project is more complex

micha14:08:08

but yeah this is also my approach, it's easy to make specific tasks that do exactly what i want

richiardiandrea15:08:32

I would add that given that the set-env! is a mutable, one time only operation, sometimes you want the with-env to pass info to tasks you are not in control of..the workaround to this in lambone is to call set-env! as late as possible (and be sure only once) and have the main shared boot pod only contain the deps (for instance) necessary to the task downstream. It works, but feels brittle a bit.

richiardiandrea15:08:55

And I had to implement a custom show for instance

richiardiandrea15:08:52

On the other end, I apologize because I didn't have too much time to for the patch above, which would solve the problem

micha15:08:57

right, this is because you want to resolve your dependencies in one shot, rather than spread across multiple calls to set-env!, because the dependency graph will be resolved differently

micha15:08:33

maven likes to have a full view of all dependencies so it can select the correct transitive dependencies when there are conflicts

richiardiandrea15:08:11

Yes the one time only constraint I think is key here, I don't even know if there is a way for maven to incrementally resolve conflicts

micha15:08:50

yeah it can't

micha15:08:17

because it doesn't know how the decisions it makes in the first dependency resolution will affect subsequent ones

micha15:08:39

once it chooses a specific version of some transitive dependency that's it, it can't change that for the second run

micha15:08:01

even if it would have preferred a different version given the info provided with the second set of depenedncies

micha15:08:34

but also this is only a problem if you don't fully resolve all of your conflicts

micha15:08:43

if you do that then there is no problem

micha15:08:03

then you yourself would have the full view

micha15:08:23

and maven won't need to worry about it, because there will be no conflicts for it to think about

richiardiandrea15:08:32

So you shift the problem to your side, mmm..interesting

richiardiandrea15:08:07

Because I do conflict resolution manually anyways with with-cp

richiardiandrea15:08:53

So I really could just say, hey maven, here it is the list, don't bother checking it :)

micha15:08:28

right it shouldn't be making any decisions if you specify which version of conflicting transitive deps you want

richiardiandrea15:08:24

I am trying to read about the problem and I found a rant, still interesting, I did not know Buck: http://blog.ltgt.net/maven-is-broken-by-design/

micha15:08:04

i'll read it, but i am highly skeptical of anyone who says maven's dependency resolution is broken

micha15:08:15

because maven is the only one i've ever used that actually works

micha15:08:27

sure you have conflicts, but you can at least resolve them

micha15:08:36

and inspect them easily

micha15:08:42

and it's 100% deterministic

richiardiandrea15:08:12

You know that is actually not talking about maven resolution, I 'll explore deeper, don't waste your time on that ah ah

micha15:08:30

it's geared more toward reliability than easy use for toy projects

micha15:08:15

is jigsaw in 1.9 finally?

micha15:08:23

or are they delaying it again?

dominicm15:08:09

I like npm's dependency resolution. If that's what we're talking about. But it's requires Mr. Anderson for Clojure.

micha15:08:39

i don't see how npm style deps could work in the jvm really

micha15:08:53

like npm modules don't export named things

micha15:08:05

you bind an instance to a lexical name when you use require

micha15:08:35

so you can have multiple versions of the same classes at the same time

dominicm15:08:47

I was talking in absolutes really. https://github.com/benedekfazekas/mranderson exists though. Not sure how it's magic works.

micha15:08:57

but this is also kind of wacky because what if you have dependencies that pass objects to each other

micha15:08:07

like dependency A creates a Foo object

micha15:08:21

and dependency B has a function that takes a Foo object and does something to it

dominicm15:08:34

Yeah, that's the big problem really.

micha15:08:50

now in your code you call the function in A that creates a Foo object of version 2.0, and you pass it to the B function that only know about 1.0 verison Foos

micha15:08:02

the classloader is a super elegant solution to this

micha15:08:18

also require() in js is slow, because of the dynamic stuff it has to do

micha15:08:30

well slow relative to loading a class from a classloader

dominicm15:08:41

Not because all of js is slow compared to the JVM?

micha15:08:52

i mean there is less caching you can do

micha15:08:11

in the jvm classes are immutable, for the most part

micha15:08:26

so the classloader can be pretty efficient

richiardiandrea16:08:04

An interesting question would be how mranderson would work for package auditing

richiardiandrea17:08:56

@micha is there a way in jt to pretty print the input json ?

alandipert17:08:30

@richiardiandrea: i pipe to python -m json.tool to pretty print, jq also does it

alandipert17:08:51

the python one is nice since it's on nearly every system already

richiardiandrea17:08:59

yeah I wanted to stick with your solution guys without installing the competitor jq 😄

richiardiandrea17:08:13

yeah the python option is cool

richiardiandrea17:08:12

this is good task for me to study ML, wasn't it written in ML?

richiardiandrea17:08:28

oh wow no it is C 😄

richiardiandrea17:08:39

alias jpp='python -m json.tool' will do for now 😄

richiardiandrea17:08:24

ahah sorry Alan did not want to cut your speech 😄

alandipert17:08:54

when you see me typing i'm usually just fumbling with my window manager keys

richiardiandrea17:08:23

lol! I just installed i3 -> tiling window manager, it is about time

alandipert17:08:16

yesss that's my fav one

richiardiandrea17:08:31

so easy to configure and I was actually using jt to hack some script 😉

micha17:08:44

man i3 is so great

micha17:08:05

i hope i can continue to run it forever

micha17:08:31

if x windows somehow becomes incompatible with it i don't know what i'll do

juhoteperi17:08:55

luckily there are plenty of people who NEED i3 even after X

richiardiandrea17:08:10

oh you guys, I am always discovering new cool things 😄

juhoteperi17:08:06

I should try Wayland soon now that I have HiDPI display on laptop and normal on desktop, X is horrible with different DPI displays

juhoteperi17:08:28

Though maybe I just fix this by buying 4k 28" display or something

juhoteperi18:08:15

And none of toolkits yet support proper scaling even with Wayland, I think

micha18:08:10

is wayland somehow better than x?

richiardiandrea18:08:35

I don't know I was thinking of buying a bigger monitor but I am one meter from it and I am worried it will feel like I am in the movie theater in the front row

micha18:08:42

i don't really care about transparent windows or desktops or windows that wiggle like jelly

juhoteperi18:08:57

For one thing, it supports per display DPI

micha18:08:07

ah like scaling?

juhoteperi18:08:30

well, it doesn't automatically mean proper scaling but it is requirement for it

micha18:08:33

that would be a big thing, yeah

juhoteperi18:08:39

Qt, GTK etc. should also support scaling

micha18:08:51

i use this script, autorandr, to manage displays

juhoteperi18:08:53

They have quite limited support currently

micha18:08:11

it can remember config for a specific monitor and set it up automatically

juhoteperi18:08:25

I have a similar script

micha18:08:33

the scaling in x looks terrible though

micha18:08:37

so i don't use that

juhoteperi18:08:15

But when switching between 14" 2560x1440 and 27" 2560x1440 displays, all the texts are either huge or small on another display

micha18:08:33

@richiardiandrea: i have one of the big 34" wide curved monitors on my desk, i like it

micha18:08:10

yeah i remember with the x1 carbon, its laptop display was the same resolution as a cinema display, but only like 11" or so

micha18:08:25

pretty much unusable without a microscope

micha18:08:56

i tried the scaling thing but it was really blurry

stuarthalloway18:08:30

it is not clear to me when I should make a pod vs. a pod pool https://github.com/boot-clj/boot/wiki/Pods

stuarthalloway18:08:58

e.g., boot-test makes a pod pool that is lexically scoped to run-tests, so it would be difficult/hacky for somebody else to share the pool. So why pool at all?

stuarthalloway18:08:52

OTOH, I might make a pod pool that could be reused across many tasks, or across many invocations of (boot) at the REPL. In that case, I want a pool, but I don’t want to kill the pool at the end of any particular task or boo invocation. So can I just omit calling :shutdown?

micha18:08:08

the main use of the pod pool is to reduce the delay when a task wants a fresh pod

micha18:08:27

some tasks run each invocation in a fresh pod, like the test task

micha18:08:39

the pool keeps a stack of pre-warmed pods ready

micha18:08:57

and also takes care of making sure they get GC

micha18:08:20

it's easy to leak pods if you make lots of them, and they're like 10M of memory sometimes

stuarthalloway18:08:41

the test task appears to be making a fresh pool (not just pod) each time, so where does the pre-warmed opportunity occur?

micha18:08:53

that would be a bug, maybe?

micha18:08:07

it should make the pool only once per pipeline

micha18:08:32

and each invocation in the pipeline would use the same pool to get pods

stuarthalloway18:08:42

where does one put code to make it have once-per-pipeline semantics

micha18:08:49

like here:

micha18:08:21

(deftask foo
  []
  (let [per-pipeline-state (is here)]
    ...

micha18:08:35

very similar to how you'd make a stateful transducer

micha18:08:07

the deftask body constructs the pipeline middleware closure

micha18:08:19

so that's the scope where you'd put per-pipeline state

stuarthalloway18:08:52

nevermind, I see it now, test use is once per pipeline

stuarthalloway18:08:04

@micha hm, still not getting it. If I call the same task twice in one pipeline, that code will run twice, yes?

micha18:08:06

yeah it should

micha18:08:11

like for example:

stuarthalloway18:08:19

(deftask foo
    []
    (println "Get per-pipeline resource")
    (with-pass-thru [_]))
  (boot (foo) (foo))

stuarthalloway18:08:10

so if I e.g. use the test task twice in one build pipeline, they don’t get to share, and are making two pools

micha18:08:05

kind of like (def my-transducers (comp (partition 2) (partition 3))) maybe

stuarthalloway18:08:16

where would I put the initialization if I want the pool to be shared, but killed at the end of the pipeline?

micha18:08:55

a dynamic binding perhaps?

micha18:08:34

if they're going to be sharing some resource it seems like that resource will need to originate outside the task itself

micha18:08:53

there is also the boot.core/cleanup macro

stuarthalloway18:08:25

yes, but I want the resource to be dependent on the environment established by a single pipeline

stuarthalloway18:08:34

and scoped to it

micha18:08:07

ah that's a good one

stuarthalloway18:08:23

I can make a globally scoped pod pool, or set of pod pools

alandipert18:08:42

you could put the pod pool on the fileset as metadata, and your task either uses it or adds it

alandipert18:08:22

or you could lift the pod pool to a def and do a promise/latch system of some kind

alandipert18:08:29

first-one-creates

micha19:08:22

^^ that's where boot.core/cleanup would come into play

micha19:08:32

that's the destructor, called when the pipeline ends

stuarthalloway19:08:35

@alandipert following that plan, can I :refresh pods from the pool into a task, and then have the task call destroy-pod

alandipert19:08:02

sounds good to me

stuarthalloway19:08:11

so the pool has bigger scope than build pipelines, and tasks tear off and manage pods from the pool

alandipert19:08:51

i can even imagine a system by which you have a task at the front that puts pods on the FS

alandipert19:08:01

and watches out for them on the return value of the subsequent task, destroying

alandipert19:08:41

but that introduces an ordering semantic i guess which is not as generally good

micha19:08:01

@stuarthalloway: the :refresh message will destroy the pod for you and make sure it's GC'd

micha19:08:33

the weird message passing is there to make it simpler to use pods from the pool without keeping any references to them

stuarthalloway19:08:36

@micha ^^ when the next pod is taken, right?

micha19:08:48

right, or when the pool is :shutdown

stuarthalloway19:08:31

isn’t refresh wasteful on a brand new pool?

micha19:08:06

how do you mean?

micha19:08:44

it should be doing the destruction asynchronously

micha19:08:55

@stuarthalloway: there is also a :take message that lets you gain ownership of a pod from the pool

micha19:08:11

then you can destroy it yourself, the pool will forget about it

micha19:08:24

not sure why it's not in the docstring

micha19:08:31

but it does exist

stuarthalloway19:08:40

@micha with a brand new pool, doesn’t :refresh kill a pod that nobody has ever had a chance to use?

micha19:08:50

it would, yes

stuarthalloway19:08:10

and yep, already switched to :take + pod/shutdown — seems strictly superior to :refresh

micha19:08:59

👍 totally

kenny20:08:26

Is it possible to customise which files cause watch to fire, possibly with a regex? Right now it looks like this is not possible.

kenny20:08:45

The use case is I have a single project with both clj and cljs sources (e.g. :resource-paths #{"src/cljs" "src/clj" "resources"}) and I only want watch to fire when a cljs or cljc file is change (e.g. #"^.*\.(cljs|cljc)$").

richiardiandrea20:08:12

have you guys seen-> https://github.com/enkore/j4-dmenu-desktop for i3...speedy speedy fast!

micha20:08:31

@kenny: there is nothing currently for that

kenny20:08:50

Thought so

richiardiandrea20:08:41

but there's a certain learning curve

juhoteperi20:08:51

Rofi also supports ordering the most often used entries top etc. (not sure about j4-dmenu-desktop)

richiardiandrea20:08:17

no well j4-menu-desktop is super basic

richiardiandrea20:08:48

I am interested in the window selector though by regex on Class or Title

mitchelkuijpers21:08:04

Are there any people here who are using this: https://github.com/ladderlife/om-css with boot-reload?

mitchelkuijpers21:08:06

this writes a css file as a output file from cljs compilation and this triggers another reload.. which basically breaks reloading 😞

mitchelkuijpers21:08:15

Hmm while I am typing this I realize i maybe should just simply not set the output path.. 😛

anmonteiro21:08:18

@mitchelkuijpers I don’t think I ever planned for that to work with Boot 😇

mitchelkuijpers21:08:59

@anmonteiro: it might work with the default out.css to the root of the project

anmonteiro21:08:42

it might. There might also be a way to tell Boot-reload not to reload a particular file?

anmonteiro21:08:28

or rather, the watch task

mitchelkuijpers21:08:45

I looked for it but unfortonately they don’t have this option

richiardiandrea21:08:29

@juhoteperi you opened a whole new world for me, try: j4-dmenu-desktop --dmenu='rofi -dmenu'

richiardiandrea21:08:44

or i3-dmenu-desktop --dmenu='rofi -dmenu' (but way slower)

richiardiandrea21:08:06

The drun⁠ switcher has not been enabled

mitchelkuijpers21:08:33

@anmonteiro: I get a very weird filename main.outout.css but it seems to work!

mitchelkuijpers21:08:45

il simply sift it and then it works

anmonteiro21:08:11

@mitchelkuijpers the weird filename is probably a result of sifting 🙂

mitchelkuijpers21:08:38

@anmonteiro: it is before the sifting, but it’s fine it works!

michael.heuberger22:08:05

hello guys, having a problem here with source maps

michael.heuberger22:08:19

dont work here when optimizations are set to none

michael.heuberger22:08:48

found out, path is incorrect like

michael.heuberger22:08:15

any clues what config could influence this?

timothypratley22:08:39

@michael.heuberger I'm not understanding the problem or how it relates to source maps?

timothypratley22:08:30

oh I see the double app.out

timothypratley22:08:51

chances are it relates to the app.cljs.edn, can you post your settings?

michael.heuberger23:08:29

@timothypratley settings … the build.boot you mean?

timothypratley23:08:28

yes but more likely ./src/cljs/js/app.cljs.edn

timothypratley23:08:35

(or whatever you have similar)