Fork me on GitHub
#boot
<
2017-02-06
>
micha00:02:08

if you put a library in a maven repo, it's polite to use :scope "test" in your POM when you declare dependencies that are not needed in prod

micha00:02:32

boot complects :dependencies and the <dependencies> of the POM by default

micha00:02:37

for better or worse

micha00:02:52

which i think also causes some confusion when people start to look at scopes and doing stuff with them

micha00:02:10

but the pom task takes a :dependencies option

micha00:02:24

which you may use to override the (set-env! :dependencies

mobileink00:02:34

ok, now i'm riily confused. scopes "don't do anything to dependencies you specify that are not transitive." ok that might be what boot means by scope, but it's not what maven means, and boot does depend, even if indirectly, on maven. no? with maven it's very clear (eventually) scopes are about classpaths, and maybe also about transirivity. thats my reading, anyway.

micha00:02:46

boot does not depen on maven

micha00:02:54

in any way at all

micha00:02:00

boot depends on apache aether

micha00:02:04

which maven also depends on

micha00:02:10

and leiningen, and probably gradle

micha00:02:20

although i think they used to use ivy at least

micha00:02:26

but probably with aether also

micha00:02:28

but anyway

micha00:02:34

aether is not a build tool

micha00:02:45

it was factored out of maven, as i understand it

micha00:02:00

because other tools started using maven repos

micha00:02:14

so people were using maven as just a package manager

micha00:02:25

and not using any of the build functionality

micha00:02:41

and it was a pain, so they cleaned things up and factored the package manager part out

micha00:02:45

that became apache aether

micha00:02:21

since the maven repo structure and POM is derived from maven the build tool, there are some things in there that are specific to building things with maven

micha00:02:30

scopes is one

micha00:02:49

scopes are basically implementation details of the maven build workflow

micha00:02:12

scopes have very little effect on aether, which is what boot uses

micha00:02:17

(and maven, too)

micha00:02:37

basically aether does this:

micha00:02:48

it takes a vector of dependency coordinates

micha00:02:08

for each one it finds the POM.xml from the maven repos it was configured to look in

micha00:02:28

and it downloads the jars for each dependency in the vector

micha00:02:31

from the repo

micha00:02:43

then it builds a graph of transitive dependencies

micha00:02:53

note that it hasn't done anything with scopes at all

micha00:02:10

now, when it builds this graph, it does consider scopes

micha00:02:21

because it's considering dependencies of dependencies

micha00:02:38

anthing but scope compile will be pruned from the graph

micha00:02:47

and that's the end

micha00:02:04

oh, yeah, then the jars for each depenedncy in the transitive deps graph will be downloaded

micha00:02:38

note also that this has nothing to do with boot

micha00:02:50

it's just what you need to do to consume dependencies from a maven repo

micha00:02:09

actually to be more precise

micha00:02:29

aether loops through your vector of dependency coordinates

micha00:02:39

for each one it finds the POM.xml in maven repo

micha00:02:51

that gives it the information it needs to download the jar, which it does

micha00:02:04

but that also gives it a list of transitive dependencies, which it will use later

micha00:02:27

once it's done looping though all your dependencies it will have all the POMs and all the jars

micha00:02:37

scopes have not affected anything yet

micha00:02:07

then it makes a graph of transitive dep coordinates

micha00:02:13

and topo sorts them

micha00:02:42

when building the tree of transitive deps it will ignore any dep with scope other than compile

micha00:02:10

and this behavior of course works transitively, like deps of deps of deps

mobileink00:02:15

ok. look, i love boot. but imho this is a really stinky wart. boot supports :scope in :dependencies. so where can i go to find out what this means? maybe im just stupid but maven seems the obvious place. now i find out that boot's :scope is a whole 'nother matter. i still luv boot, but i admit this is a little discouraging. maybe we can clarify this somehow in the docs? it seems like kind of a bigly deal.

micha00:02:17

it has to download all the POMs

micha00:02:54

i would just not worry about scope other than "compile" and "test"

micha00:02:57

that's all you need

micha00:02:58

use scope "test" if you are making a library that will be loaded as a dependency of another library or application, and your library that you're making has dependencies that are not wanted in prod

micha00:02:03

otherwise don't use any scope

micha00:02:12

that's all you need really

mobileink00:02:54

fwiw, if anything other than "compile" and "test" is meaningless, the boot should throw an exception in thise cases. nothing worse than a silent error.

micha00:02:00

or, alternatively, you can just forget about scopes entirely, and provide a :dependencies vector to the pom task when you make your libraries POM, and just don't include any dependencies that are not wanted in prod

micha00:02:24

i don't think boot should throw an exception for every useless thing

micha00:02:38

what if someone is writing a pom that will be used to build a project with maven?

micha00:02:42

for example

richiardiandrea00:02:44

yep, I think that using boot-cp is a must for big uberjars

micha00:02:46

maven does use scopes

micha00:02:09

the pom task just makes you a POM

micha00:02:34

i don't think we want it to enforce boot best practices or anything

micha00:02:58

if you're not making a POM then you really can ignore scopes

micha00:02:12

because scopes do exactly zero when they're not read by aether from a POM.xml

micha00:02:34

^^ from a POM.xml it downloaded from a maven repo even

richiardiandrea00:02:06

@micha talking about maven, yesterday I added :parent to pom, and I was wondering if you are planning a release soon-ish (there a bunch of very good PRs in there) 👼 👼 👼

micha00:02:25

oh yeah, i'll start getting things ready tonight

micha00:02:49

perhaps make a release tomorrow or in a few days?

richiardiandrea00:02:58

oh tomorrow would be great, some PRs have been reviewed by me, Martin, Brent, others...

richiardiandrea00:02:43

Also I left the relativePath out of :parent as we might not need it at all...but I wanted your opinion on splitting task args this way: https://github.com/boot-clj/boot/pull/579/files/f0aa92b7ebc4d1ae6ce9fdf5314052b501427658#diff-a4c54fc631a18b940822c4cc9a9251e1

richiardiandrea00:02:04

I mean the code (and tests) is in, the option not there

micha00:02:07

does SYM:VER=PATH not work?

micha00:02:16

seems like it should work

micha00:02:37

maybe there's a regression?

richiardiandrea00:02:21

I'll check, you confirm it should work right?

micha00:02:57

yeah, i mean it seems like it should work

micha00:02:20

interesting

micha00:02:25

do you get a type error there?

micha00:02:22

hm yeah it looks like something is broken in there

mobileink00:02:22

@micha: dammit, you guys are so far ahead of me it makes me puke! i'm beginning to grok the wisdom of boot's handling of scopes. even if boot ignores :scope "provided" (or whatever), it's still there, so i can write my own "prod" task, and filter stuff on :scope. yeah?

micha00:02:01

@mobileink sure, or you could even make your own key

micha00:02:25

i think you want to be careful about what you put into POMs that you will upload to a maven repo

micha00:02:42

like to not interfere with maven users, for instance, who want to use your library as a dependency

micha00:02:04

but you could also filter dependencies before sending them to set-env!

micha00:02:58

i guess the important thing to know is that scopes are hints for aether to know which dependencies to prune from the transitive dependency tree

micha00:02:23

and it happens to be that any scope other than "compile" will be pruned

juhoteperi01:02:33

I started testing alternative way to serve files during development, which fixes problem with clojure.tools.namespace & cljc files in cljs output and only serves files with output role: https://github.com/Deraen/saapas/pull/15

richiardiandrea01:02:05

@juhoteperi the idea is for sure interesting, are you then adding tmp-dir to the fileset ?

juhoteperi01:02:23

Idea is that the output files are not in fileset or classpath after this task

richiardiandrea01:02:10

ok so basically it is writing on a "normal" folder, without fileset enhancement

richiardiandrea01:02:51

so no caching (but it might make sense if the compiler caches) / no immutability

juhoteperi01:02:40

Hmm, it uses the Boot filesystem utilities to write files to the output directory

juhoteperi01:02:48

So it should be efficient

juhoteperi01:02:57

The same as target task

juhoteperi01:02:19

And this doesn't affect Cljs caching at all, because Boot-cljs keeps compiler state on it's own tmp-dir

richiardiandrea01:02:30

yeah, this is what I meant, it is effectively executing the compile in a "normal" environment, as if it was launched from a build.clj (it might actually solve some slowness I have noticed in boot-cljs)

juhoteperi01:02:48

No, this doesn't affect boot-cljs at all

juhoteperi01:02:13

It works the same as always, this only changes how application can access the output files

juhoteperi01:02:53

Due to how I constructed pipeline and the middleware, other tasks never know anything about catch-output

richiardiandrea01:02:44

k I will explore the patch better

richiardiandrea02:02:07

just gave a shot at another thing that has bothered me for long time: the sift output 😄 Now it is only dbug* and more meaningful 😄

clodeindustrie05:02:23

hi there, I'm trying to compile some sass files with boot-sass on my project, one of the file references my node_modules directory at the root of the project, does Boot has access to files outside of the source-paths and resource-paths?

pesterhazy07:02:13

no, and I wouldn't recommend adding node_modules to the source paths as that directory contains a ton of files (and boot automatically watched source directories for modifications)

pesterhazy07:02:27

not sure how to do what you're trying to accomplish... copy the files from node_modules to your repo?

clodeindustrie07:02:33

absolutely not intending to add node_modules to the source-paths 🙂, yeah not sure how other people do it, I have seen mentions of people using Webjars but I’m not sold yet

ska09:02:35

Hi. Is there a recommended release plug-in for boot?

pesterhazy09:02:15

@ska, for open source projects?

ska09:02:44

@pesterhazy in this particular case, no. I am basically looking for a boot replacement for the maven release plug-in. And I am aware that there is criticism for that plug-in, so maybe in boot-land it is just not considered worth the effort?

pesterhazy09:02:14

could that be sufficient?

pesterhazy09:02:42

N.b.: I don't know the requirements of working in a shared java/clojure environment

ska09:02:30

@pesterhazy I would expect the basics like remove SNAPSHOT, commit, tag, push, increase version number&add SNAPSHOT again, commit.

pesterhazy09:02:47

There is bootlaces

pesterhazy09:02:12

I built my own functions for this

pesterhazy09:02:38

But I can see automating this could be useful

micha14:02:32

@ska i wish i could remember who made it, i am 50% sure it's @flyboarder ... but there are some boot tasks for manipulating versions and whatnot for release

micha14:02:00

one thing you can do that is i think pretty simple is have a version.properties file

micha14:02:13

that's really easy to edit with shell tools and in clojure/java

micha14:02:44

you can reference values in the version.properties file from your build.boot

micha14:02:08

also update it etc

mitchelkuijpers15:02:18

@juhoteperi That looks very interesting should this make it possible to start seperate tasks to compile cljs, because that seems very helpfull

juhoteperi15:02:50

@mitchelkuijpers That is possible using similar approach, but is not my goal

juhoteperi15:02:09

And that won't work with Boot-reload

juhoteperi15:02:27

Or well, it will work it the reload is on same pipeline as cljs

mitchelkuijpers15:02:00

Ah sure that makes sense, what is the problem then that it solves?

juhoteperi15:02:18

The PR lists three problems it solves

mitchelkuijpers15:02:01

Ah will read that thank you

pesterhazy15:02:49

When working on boot proper (specifically built-in task), I make a change, make install to a freaky version (like 2.7.999) and the use BOOT_VERSION to try it out. Is there quicker way?

micha15:02:34

@pesterhazy usually i will prototype things in a separate namespace first

pesterhazy15:02:04

ah and then try it out using (boot...)

micha15:02:24

boot's build process is kind of complicated

micha15:02:37

because of how things need to be organized into pods and aot

pesterhazy15:02:32

yeah that's understandable

pesterhazy15:02:53

I've opened a RFC PR, curious what people think: https://github.com/boot-clj/boot/pull/582

pesterhazy15:02:15

A bare repl is useful for quick experiments, for debugging (to rule out nREPL-releated problems), for direct tty access and probably other use cases

micha15:02:10

i definitely like the idea of a non-nREPL option

richiardiandrea16:02:35

At times point I was actually using cider.diet: https://github.com/kovrik/cider-diet/blob/master/src/cider/diet.clj and front a task for it. An nrepl non in a pod is definitely useful

richiardiandrea16:02:09

I wonder how slower would it be with the middleware

pesterhazy16:02:46

cider-diet looks interesting as well

richiardiandrea16:02:19

Yeah it basically does the same thing as you do, plus requiring cider.nrepl

pesterhazy16:02:29

why do you spawn another java process?

richiardiandrea16:02:55

Good question , I should not do it 😀

pesterhazy16:02:41

I thought that it might be a neat idea to make a fast-repl generator task

pesterhazy16:02:15

that spits out ./quick-repl.sh, which contains java -cp contents-of-boot-cp clojure.main or something like that

pesterhazy16:02:29

so you can run that, and it should be quicker

richiardiandrea16:02:29

Ahahah yeah good idea

pesterhazy16:02:51

still, usability is not amazing

pesterhazy16:02:06

if you change your build.boot you need to remember to re-generate your quick-repl script etc

richiardiandrea16:02:12

But you probably need a bash generator

pesterhazy16:02:00

well it's just a single line #!/usr/bin/env bash\njava -cp $CP ...

pesterhazy16:02:04

two lines 🙂

richiardiandrea16:02:09

It was a quick hack to see if things were faster, but I should make a boot task

richiardiandrea16:02:33

No yes but if you have a boot generator you pay the cost of starting the JVM...probably a Lumo script that could read a file with the dependencies and spawn a shell process would be ideal

richiardiandrea16:02:57

Just thinking aloud 😀

pesterhazy16:02:31

hmm I'm a bit skeptical about being able to read build.boot from lumo

pesterhazy16:02:20

it's clojure code, not a declarative list of dependencies after all

richiardiandrea16:02:42

Yep no that would be hard, you would need to use edn for declaring your conf, like https://gist.github.com/arichiardi/7e4c430ff4ead706392f22e77c85b16a

richiardiandrea16:02:11

I have a macro which parses and creates boot tasks

richiardiandrea16:02:48

It would be the same but spawning a process

qqq18:02:17

does anyone have a boot electron tempalte I can use? I have tried the frist two "clojurescript electron" github repos, but getting ewird errors

qqq18:02:27

if I can just get a working skeleton to build off of, life would be so much easier

mobileink18:02:41

boot is loading the wrong version of cider-nrepl. I followed all the instructions on the wiki, specifying [cider/cider-nrepl “0.14.0”] in my ~/.boot/profile.boot, but 0.13.0 is getting loaded.

micha18:02:29

@mobileink how are you specifying it in profile.boot?

micha18:02:35

could you paste that part please?

mobileink18:02:55

(deftask cider "CIDER profile" [] (println "FOOBAR") (require 'boot.repl) (swap! @(resolve 'boot.repl/default-dependencies) concat '[[org.clojure/tools.nrepl "0.2.12"] [cider/cider-nrepl "0.14.0"] [refactor-nrepl "2.2.0"]]) (swap! @(resolve 'boot.repl/default-middleware) concat '[cider.nrepl/cider-middleware refactor-nrepl.middleware/wrap-refactor]) identity)

mobileink18:02:58

sorry, the dissappeared, it actually says *default-dependencies and default-middleware

mobileink18:02:18

well, you get the idea, the asterisks are there in the code

micha18:02:23

you can use 3 backticks to quote code, if you want

micha18:02:33

or the snippet thingy

mobileink18:02:00

ok, let’s try again:

mobileink18:02:11

(deftask cider "CIDER profile"
  []
  (println "FOOBAR")
  (require 'boot.repl)
  (swap! @(resolve 'boot.repl/*default-dependencies*)
         concat '[[org.clojure/tools.nrepl "0.2.12"]
                  [cider/cider-nrepl "0.14.0"]
                  [refactor-nrepl "2.2.0"]])
  (swap! @(resolve 'boot.repl/*default-middleware*)
         concat '[cider.nrepl/cider-middleware
                  refactor-nrepl.middleware/wrap-refactor])
  identity)

mobileink18:02:22

when i run cider-jack-in I get:

Starting nREPL server via /usr/local/bin/boot -d org.clojure/tools.nrepl\:0.2.12 -d cider/cider-nrepl\:0.13.0 cider repl -m cider.nrepl/cider-middleware -s wait…

mobileink18:02:12

same thing if I start from the cl:

boot cider repl
and then use cider-connect.

mobileink18:02:14

wait, in both cases I get

;; Connected to nREPL server - 
;; CIDER 0.14.0 (California), nREPL 0.2.12

mobileink18:02:48

but with cider-connect I get the notorious

WARNING: CIDER's version (0.13.0) does not match cider-nrepl's version (0.14.0). Things will break!
. so i guess i can ignore that warning?

micha18:02:15

ah you're specifying the other version on the command line there

micha18:02:29

Starting nREPL server via /usr/local/bin/boot -d org.clojure/tools.nrepl\:0.2.12 -d cider/cider-nrepl\:0.13.0 cider repl -m cider.nrepl/cider-middleware -s wait…

micha18:02:36

those -d options

micha18:02:42

so that makes sense

mobileink18:02:45

that message is printed by cider-jack-in

mobileink18:02:57

i don’t know where it comes from.

micha18:02:10

it's overriding your settings, basically, via command line options

mobileink18:02:23

must be sth in the cider-jack-in cmd i guess

richiardiandrea18:02:27

@mobileink I have pushed a couple of patches to the new cider, you might want to use 0.15.0-SNAPSHOT, basically you don't need the cider task anymore

richiardiandrea18:02:47

so you will see a different Starting nREPL line...if you don't like to upgrade. Make sure the cider-nrepl version in the cider task matches the version installed in your emacs

richiardiandrea18:02:32

the Starting nRepl line includes a -d option with the version of cider that your emacs is including

mobileink18:02:51

where is it getting that? must be some cider config var, i haven’t set it to 0.13.0, that I know of.

mobileink18:02:13

anyway it seems to be running, I’m just going to ignore the warning until something breaks.

anmonteiro18:02:18

@juhoteperi I'm having a problem where boot-reload doesn't seem to be reloading the Clojure namespace where my macros are?

anmonteiro18:02:21

is this possible?

richiardiandrea18:02:06

@mobileink there is no way to set a different version at the moment, it is baked with the cider package

mobileink18:02:42

ok, specifying 0.13.0 in profile.boot eliminates the warning.

juhoteperi18:02:07

@anmonteiro Boot-reload doesn't reload namespaces, Boot-cljs does that. Boot-reload only cares about changed JS files.

anmonteiro18:02:47

OK wrong package, same bug? 🙂

richiardiandrea18:02:21

@mobileink yep see above cider-nrepl has to be the same version as the installed cider

juhoteperi18:02:40

Well, it should work, but there are probably some corner cases with cljc files or such

juhoteperi18:02:34

You can try verbose mode to check if that code correctly sees the changed namespace

anmonteiro18:02:00

this is a cljc file

anmonteiro18:02:06

which requires its own macros

juhoteperi18:02:17

It is possible that ns-tracker get's confused if there is cljc namespace which both is cljs namespace and macro namespace

juhoteperi18:02:41

I think only c.t.n 0.3 alpha supports this and ns-tracker is still using 0.2.11

juhoteperi18:02:34

But checking debug output should be good place to start checking if the problem is with reloading the clj namespace, or with cljs not recompiling dependent namespaces

mobileink18:02:06

@richiardiandrea @micha: the secret is to delete and reinstall the cider emacs package. then you can use the latest matching cider-nrepl (0.14.0)

richiardiandrea20:02:57

@micha what do you use nowadays for calling stuff in separate classloaders? I am in a maven plugin and I am evaluating if I want classlojure or dynapath

micha20:02:22

dynapath is a different thing entirely

micha20:02:35

you want to use clojure?

richiardiandrea20:02:19

I would like to execute clojure without having to specify deps in maven

richiardiandrea20:02:32

so the plugin will inject deps

micha20:02:15

yeah i didn't have much luck with that one

micha20:02:28

or pods would have been very simple to implement 🙂

micha20:02:36

you can use shimdandy

micha20:02:44

i would think

richiardiandrea20:02:50

ok thanks! I'll try that

richiardiandrea21:02:22

@micha I ended up using boot.pod in the deps, now I am trying to create a pod with clojure in it

richiardiandrea21:02:38

yeah definitely something weird with the options :pom {:parent {'org.sonatype.oss/oss-parent "5"}} fails with java.lang.IllegalArgumentException: option :parent must be of type [sym str]

michael.heuberger22:02:23

hello folks - is there a recipe how to run CLJ and CLJS tests both within a single boot task? have here clj namespaces in an env folder, and cljs namespaces in a src folder.

qqq22:02:15

is the current behaviour of boot/watch to just die if a file it's watching is deleted ?

qqq22:02:38

I'm having this issue where org-tangle is creating a temporary file .#main.cljs -- and when this file is deleted, boot throws an uncaught exception

michael.heuberger22:02:05

never mind, got it working now by using CLJC files

micha22:02:16

@qqq the filesystem is not transactional so there are all kinds of issues that can't be fixed by boot there

micha22:02:30

especially if something is going crazy creating and deleting files

micha22:02:46

the best thing to do is to have editors and stuff keep their lockfiles or whatever in another place

micha22:02:03

but you can use a .bootignore file to have boot ignore those

qqq22:02:20

is there a way to wrap the (comp (watch) .... ) in a "just restart everything instaed of killing the jvm on error" ?

micha22:02:29

the problem is that it's an unhandled exception

micha22:02:39

you could make a task that catches exceptions

micha22:02:53

and reruns the next handler

micha22:02:23

you can see how that would be done by looking at the watch task

micha22:02:49

watch does what you want, except instead of restarting stuff when an exception is raised, it does it when something changes

micha22:02:16

another way to achieve what you want is to run (boot ... in the repl

micha22:02:20

instead of from the command line

qqq22:02:23

oh right

micha22:02:40

the problem isn't that boot is killing the jvm

micha22:02:46

it's that the pipeline just ends

micha22:02:03

so there are no more expressions to evaluate, and the program exits

qqq22:02:52

just running a repl is a uch better solution; I got way too carried away with my elisp ide

qqq22:02:10

oe more question: .#main.cljs <-- this si a emacs lock file? I can't find this documented anywhere, and googling for ".#" has not been helpful

micha22:02:44

it's some kind of journal or writeahead log or something probably

micha22:02:53

in case the editor crashes

qqq22:02:11

the "incase editor crashes files" is #main.cljs#