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

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

for better or worse

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

but the pom task takes a :dependencies option

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

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.

boot does not depen on maven

in any way at all

boot depends on apache aether

which maven also depends on

and leiningen, and probably gradle

although i think they used to use ivy at least

but probably with aether also

but anyway

aether is not a build tool

it was factored out of maven, as i understand it

because other tools started using maven repos

so people were using maven as just a package manager

and not using any of the build functionality

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

that became apache aether

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

scopes is one

scopes are basically implementation details of the maven build workflow

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

(and maven, too)

basically aether does this:

it takes a vector of dependency coordinates

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

and it downloads the jars for each dependency in the vector

from the repo

then it builds a graph of transitive dependencies

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

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

because it's considering dependencies of dependencies

anthing but scope compile will be pruned from the graph

and that's the end

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

note also that this has nothing to do with boot

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

actually to be more precise

aether loops through your vector of dependency coordinates

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

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

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

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

scopes have not affected anything yet

then it makes a graph of transitive dep coordinates

and topo sorts them

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

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

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.

it has to download all the POMs

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

that's all you need

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

otherwise don't use any scope

that's all you need really

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.

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

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

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

for example

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

maven does use scopes

the pom task just makes you a POM

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

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

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

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

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

oh yeah, i'll start getting things ready tonight

perhaps make a release tomorrow or in a few days?

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

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

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

does SYM:VER=PATH not work?

seems like it should work

nope

yeah I know

maybe there's a regression?

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

yeah, i mean it seems like it should work

interesting

do you get a type error there?

I get this one: https://github.com/boot-clj/boot/issues/578

hm yeah it looks like something is broken in there

@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?

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

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

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

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

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

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

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

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

No

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

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

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

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

So it should be efficient

The same as target task

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

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)

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

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

k

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

k I will explore the patch better

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 😄

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?

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)

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

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

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

@ska, for open source projects?

@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?

Boot comes with push built in: https://github.com/boot-clj/boot/blob/master/doc/boot.task.built-in.md#push

could that be sufficient?

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

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

Ah I see

There is bootlaces

I built my own functions for this

But I can see automating this could be useful

@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

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

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

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

also update it etc

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

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

And that won't work with Boot-reload

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

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

The PR lists three problems it solves

Ah will read that thank you

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?

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

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

yea

boot's build process is kind of complicated

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

yeah that's understandable

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

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

i definitely like the idea of a non-nREPL option

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

I wonder how slower would it be with the middleware

cider-diet looks interesting as well

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

I was using it with this: https://gist.github.com/arichiardi/86ccc450e243e9964e723d73f2f1db2c

why do you spawn another java process?

Good question , I should not do it 😀

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

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

so you can run that, and it should be quicker

Ahahah yeah good idea

still, usability is not amazing

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

But you probably need a bash generator

Yeah that too

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

two lines 🙂

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

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

Just thinking aloud 😀

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

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

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

I have a macro which parses and creates boot tasks

Fr;m edn

It would be the same but spawning a process

@micha @ska http://github.com/degree9/boot-semver

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

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

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.

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

could you paste that part please?

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

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

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

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

or the snippet thingy

ok, let’s try again:

`

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

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…

same thing if I start from the cl:

boot cider repl

wait, in both cases I get

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

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!

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

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…

those -d options

so that makes sense

that message is printed by cider-jack-in

i don’t know where it comes from.

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

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

@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

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

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

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

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

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

is this possible?

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

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

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

OK wrong package, same bug? 🙂

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

@richiardiandrea @micha: thanks

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

https://github.com/boot-clj/boot-cljs/blob/master/src/adzerk/boot_cljs/impl.clj#L127

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

this is a cljc file

which requires its own macros

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

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

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

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

@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

dynapath is a different thing entirely

you want to use clojure?

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

so the plugin will inject deps

I have seen https://github.com/ninjudd/classlojure does that

yeah i didn't have much luck with that one

or pods would have been very simple to implement 🙂

yeah true

you can use shimdandy

i would think

ok thanks! I'll try that

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

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]

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.

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

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

never mind, got it working now by using CLJC files

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

especially if something is going crazy creating and deleting files

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

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

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

@micha: ^^

the problem is that it's an unhandled exception

you could make a task that catches exceptions

and reruns the next handler

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

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

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

instead of from the command line

oh right

the problem isn't that boot is killing the jvm

it's that the pipeline just ends

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

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

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

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

in case the editor crashes

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