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

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

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

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

hm I just can't push at all currently

I've just pushed to clojars

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

https://github.com/adzerk-oss/bootlaces/blob/master/src/adzerk/bootlaces.clj#L82

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

¯\(ツ)/¯

Yeah that's what I figured

one thing you can try is not setting the env vars

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

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

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?

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

@anmonteiro, will try that

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

Looks pretty much like:

(deftask generate [] (with-pre-wrap fs (let [...] (-> fs (add-resource tmp) commit!))))
(comp (generate) (aot :namespace #{'my.generated-ns})

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

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

@anmonteiro, your comment led me to the solution

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

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")}))]])

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

oopsie

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.

It only contains the resources

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

yeah

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

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

(or cljs in an application)

that's ... surprising 🙂

@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

@alandipert, of course that fixed it 🙂

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

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

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))

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

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)

@stuarthalloway: ^^

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

oh right

there is the with-env approach

@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

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

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

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

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

yes you should be able to

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

@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

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

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

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

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

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

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

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

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

by altering boot.pod/env and then restoring it

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

that's the with-env approach

but if the task is written like this

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

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

then that approach won't work

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

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

because it's certainly just an oversight

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

there is also this issue https://github.com/boot-clj/boot/issues/468

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

tasks use pools of pods too though

which are created dynamically while the pipeline runs

i guess it could take like a prototype pod perhaps

but then you might as well just have the env map

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

to construct the new pods

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

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

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

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

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

yep

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

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

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

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

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

but just for the test task

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

like maybe ring or whatever

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

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

totally

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

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

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.

And I had to implement a custom show for instance

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

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

Yep

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

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

yeah it can't

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

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

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

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

if you do that then there is no problem

then you yourself would have the full view

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

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

Because I do conflict resolution manually anyways with with-cp

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

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

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/

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

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

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

and inspect them easily

and it's 100% deterministic

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

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

I also discovered jdeps, which I did not know: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012485.html

is jigsaw in 1.9 finally?

or are they delaying it again?

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

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

like npm modules don't export named things

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

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

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

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

like dependency A creates a Foo object

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

Yeah, that's the big problem really.

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

the classloader is a super elegant solution to this

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

well slow relative to loading a class from a classloader

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

i mean there is less caching you can do

in the jvm classes are immutable, for the most part

so the classloader can be pretty efficient

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

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

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

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

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

yeah the python option is cool

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

oh wow no it is C 😄

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

ahah sorry Alan did not want to cut your speech 😄

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

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

yesss that's my fav one

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

man i3 is so great

i hope i can continue to run it forever

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

micha: https://github.com/SirCmpwn/sway

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

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

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

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

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

is wayland somehow better than x?

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

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

For one thing, it supports per display DPI

ah like scaling?

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

that would be a big thing, yeah

Qt, GTK etc. should also support scaling

i use this script, autorandr, to manage displays

They have quite limited support currently

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

I have a similar script

the scaling in x looks terrible though

so i don't use that

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

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

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

pretty much unusable without a microscope

i tried the scaling thing but it was really blurry

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

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?

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?

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

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

the pool keeps a stack of pre-warmed pods ready

and also takes care of making sure they get GC

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

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

that would be a bug, maybe?

it should make the pool only once per pipeline

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

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

like here:

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

very similar to how you'd make a stateful transducer

the deftask body constructs the pipeline middleware closure

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

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

thanks @micha !

👍

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

yeah it should

like for example:

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

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

exactly

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

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

a dynamic binding perhaps?

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

there is also the boot.core/cleanup macro

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

and scoped to it

ah that's a good one

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

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

@alandipert: yes

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

first-one-creates

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

that's the destructor, called when the pipeline ends

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

sounds good to me

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

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

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

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

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

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

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

right, or when the pool is :shutdown

isn’t refresh wasteful on a brand new pool?

how do you mean?

it should be doing the destruction asynchronously

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

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

not sure why it's not in the docstring

but it does exist

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

it would, yes

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

👍 totally

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

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)$").

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

@kenny: there is nothing currently for that

Thought so

@richiardiandrea: https://github.com/DaveDavenport/rofi

oh wow

but there's a certain learning curve

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

no well j4-menu-desktop is super basic

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

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

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

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

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

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

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

or rather, the watch task

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

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

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

wonderful

@richiardiandrea: rofi -show drun

The drun⁠ switcher has not been enabled

😄

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

il simply sift it and then it works

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

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

hello guys, having a problem here with source maps

dont work here when optimizations are set to none

found out, path is incorrect like

but should be

any clues what config could influence this?

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

oh I see the double app.out

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

@timothypratley settings … the build.boot you mean?

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

(or whatever you have similar)