@lilymgoh: This might be off, but are you using boot in a folder with a build.boot file?

@jamesleonis: No

It erred in the root directory as well

What version of Java are you running?

"1.8.0_05"

So far the same as my setup...

I just tried uninstalling it from homebrew, blowing away my m2 and .boot directory, and reinstalling it. So far it works.

Yup, I did that as well

Also tried restarting, that didn’t work as well 😞

Instead of installing it through homebrew, have you tried the manual install method? https://github.com/boot-clj/boot#unix-linux-osx

Nope

I wonder if that’s the problem though, but I’ll give it a shot

I don’t think so, but the obvious suspects are innocent here

Jarusvasunt@LilyJ ~> brew uninstall boot-clj
Uninstalling /usr/local/Cellar/boot-clj/2.5.2... (2 files, 6.6K)
Jarusvasunt@LilyJ ~> sudo bash -c "cd /usr/local/bin && curl -fsSLo boot  && chmod 755 boot"
Password:
Jarusvasunt@LilyJ ~> boot
clojure.lang.ExceptionInfo: Unable to resolve symbol:  in this context
    data: {:file
           "/var/folders/z_/ffgkd2vx1njf0bgs8vvngn600000gn/T/boot.user9003804281974570463.clj",
           :line 0}
java.lang.RuntimeException: Unable to resolve symbol:  in this context
               ...                
boot.main/-main/fn   main.clj: 192
   boot.main/-main   main.clj: 192
               ...                
  boot.App.runBoot   App.java: 390
     boot.App.main   App.java: 467
               ...                
         Boot.main  Boot.java: 258
Jarusvasunt@LilyJ ~ [1]> 

exact same error 😞

I’m on OSX 10.11.4, btw

I’m on 11.3. I’m going to update and see if that is the problem

brb

Welp, still works with 11.4 on my box

Oh well, thanks anyway. I'll try more later.

😞

I have a couple of feedback points about boot I have configured my profile.boot with this

(configure-repositories!
 (let [creds-file (File. (boot.App/bootdir) "credentials.gpg")
       creds-data (gpg-decrypt creds-file :as :edn)]
   (fn [{:keys [url] :as repo-map}]
     (merge repo-map (creds-data url)))))

However, it gets called everytime I use boot, which is a bit of a pain for me because it involves me unlocking my gpg private key each time - whereas with lein it was only when I was actually deploying to clojars (and not the rest of the time, like when I'm offline)

The other feedback point is that I've ended up with

(push :file "target/mylib-1.0.0-SNAPSHOT.jar")

It seems there should be a way of 'deriving' the target file without hardcoding the project name and version - it feels redundant to me - is there a better way?

This helped me a lot: https://lionfacelemonface.wordpress.com/2015/04/11/advanced-boot-scripting/

It would be somewhat nicer in boot if the repo-map could be lazy, such that the credentials were only sought once it a repo has been determined

WARNING: Unknown compiler option ':warning-handlers’

clojure
                 [adzerk/boot-cljs              "1.7.228-1"        :scope  "test”]
                 [org.clojure/clojurescript      "1.8.34"]

@isaac: Bug in clojurescript, will be fixed in next release

Ok

Should I use clojurescript 1.8 now?

The warning doesn't cause problems, you can use it if you want. If you don't want to see the warning keep using 1.7.

Boot-cljs should be mostly version agnostic nowadays, I will probably change the version scheme in future.

That ok. the warning just confuse me. I will use 1.8 if no problem

@juhoteperi: thanks

It would be nice if boot supported the automatic lookup of gpg credentials from a user's $HOME/.boot directory - I've had to jump through quite a few hoops to get something that is optimal. Do you think there would be much appetite for this if I created a PR?

https://github.com/boot-clj/boot/wiki/Repository-Credentials-and-Deploying#encrypted-credentials-file

Not sure what is the opinion making it more automatic, if I recall correctly it was decided to leave to use to select where to load the creds from

I have a problem with the current implementation, the GPG decrypt is called each time I open boot which means I would need to have yubikey always attached

Yes, those are the instructions I followed. I think the decrypt on every run aspect of configure-repositories! in that wiki is a little severe though - and there should be a sensible default that works for most users

Lein only calls decrypt when it needs creds, i.e. when doing deploy

Yes, I have the very same problem! I have a yubikey on my keyring, and I don't want to keep it plugged in for normal 'offline' development, I only want to plug it in when i do crypto, and take it out when I'm done

for what it's worth, he's what I'm doing in my profile.boot

;; Get credentials from a GPG encrypted file.
(defn decrypt-creds [url]
  (let [creds-file (java.io.File. (boot.App/bootdir) "credentials.gpg")
        creds-data (boot.core/gpg-decrypt creds-file :as :edn)]
    (some #(when (re-seq (first %) url) (second %)) creds-data)))

(defn repo-map [repo]
  (case repo
    "clojars" (let [url ""]
                (merge {:url url}
                       (decrypt-creds url)))
    (throw (ex-info "Unknown repo" {:repo repo}))))

Then I call (repo-map "clojars") in my deploy task - e.g.

(push :repo-map (repo-map "clojars"))

obviously that's suboptimal because it requires someone's got the same set up as me in their profile.boot

Yeah

I have just decrypted the creds file

The decrypt-creds is more complex because I put regexes in my credentials.gpg

But there's nothing in my profile.boot that couldn't reasonably go into boot.core, imho

as a 'reasonable' default, you should always have the option of providing your own logic in profile.boot, but it should be for escaping the defaults, not simply trying to follow the happy path

and gpg encryption of creds should arguably be the default - because security

I think before we try to decide the reasonable defaults we should create a way to decrypt deploy creds only when needed

maybe something like configure-deploy-repositories!

Yeah GPG encryption is reasonable default, but I'm not sure how important it is for people who already have encrypted disk

I agree. By the way, that's what my repo-map function is for - it's lazy in that I only call it when it's needed. It's not a great solution but something that is lazy in boot would be good

An encrypted disk offers no protection at all if your computer is on

Mine usually is!

Should be quite hard to access the files if computer is locked

or suspended

And since lein has already established this as a common practice, there's lots of resources out there about how to set it up.

I still wouldn't put all my passwords in a clear-text file - I'm happy that they're in credentials.gpg - and if I accidentally copy that file somewhere I don't have to worry about it ending up at github

And my hard disk is encrypted

But anyway, something should be done to improve the overall experience of setting up a project to push a simple library to clojars - it took me a lot longer than I had expected

Yeah

Issue describing the problems should be a good start

Or maybe two issues

1. decrypt deploy creds only when needed, 2. better overall experience

https://github.com/boot-clj/boot/issues/432

@micha: I think the current "2.6.0-SNAPSHOT" development model is quite confusing, especially if the branch is rebased against master. I think it would be better to have default branch (master or develop) which would have the most up-to-date code and PR's would be merged into this. If we need to make bugfix releases to current minor version, we could have separate branches for that.

@juhoteperi the 2.6 branch isn't rebased...what is confusing there?

PR's are made against master branch but some include 2.6 commits

so the diff is a mess

yeah, pr against master is a mess

Sure, PR's could be made against different branch, but it should be documented at least

And I think it would most obvious that the default branch is where development for next release happens, and that is the target for PRs

ok yeah if you want to merge the 2.6 branch and use the method you described going forward i think that would be good

Ok, I'll do that. There is one or two simple PRs I would like to merge also.

👍

this will also keep the github crawler bots happy with our progress lol

For some reason e.g. https://github.com/boot-clj/boot/pull/394 is still a mess

I think maybe 2.6.0 branch was rebased since that was created?

i don't think that branch was ever rebased

Hmm, yeah all the commits have same sha

i think we made that branch because of the issues with rebasing

Manual merge worked as expected

i am pretty stoked to have tests

I think this should be safe to merge also: https://github.com/boot-clj/boot/pull/416/files

👍

I think that should take care of trivial PRs. I think several others are fine also (tests, filter by metadata/properties, compile path)

Not sure about option docstring formatting.

you have reservations about that one?

I think the current format looks a bit better, maybe better fix for cases where it doesn't fit would be to allow completely skipping formatting?

^:raw "This option is not formatted"

... except strings can't have metadata 😞

i think it would have been better maybe to have designed that part to accept c style % directives

rather than trying to construct the docstring in the macro completely

maybe

Yeah something like that.

i'd really like to eventually have boot emit man pages

so you have plenty of space to describe things

like in cli mode at least

i looked everywhere though and could not find a java troff implementation

so windows would be a problem

yeah i think you're right, we could leave it as it is

it's quirky, but at least the logic is simple and consistent

so it's not hard to get used to the quirks

changing things might just aggrevate the problem

^ any ideas how easy it would be to read properties files in Bash? Maybe just using source as properties files should be valid shell scripts?

that would be hard to support in windows

windows has separate wrapper anyways?

there is no script in windows

it's an exe

i guess it's ok maybe because there is an ini file you edit in windows

yeah we could do it in bash though, no problem

i don't think we could just source the file because the values don't need to be quoted

java just splits on the first = i think

Probably it would be best to grab just those two specific keys from the file, so other variables are not accidentally set

right

we'd want to get the jvm options and the maven setup ones

and export them as env vars unless those env vars are already set

because env vars should override the files

Right

What are the maven vars? LOCAL_REPO?

in 2.6.0 there is also BOOT_CLOJARS_REPO, BOOT_CLOJARS_MIRROR, BOOT_MAVEN_CENTRAL_REPO, and BOOT_MAVEN_CENTRAL_MIRROR

actually i don't think those need to be set in the env

because boot reads them before trying to fetch anything

from the file

maybe it's just BOOT_JVM_OPTIONS actually

was there another one that needed to be set in the environment?

ah BOOT_JAVA_COMMAND

although putting that in a file seems like a footgun to me

i guess we shouldn't judge though

people know what they're doing

i can add that to the boot-bin shim

i was also thinking about adding an option to boot

like currently we have this

-e --set-env KEY=VAL        Add KEY => VAL to project env map.

people have used this to implement "flavors" like this

boot -e flavor=dev ...

and in their task they can do (get-env :flavor)

but i think it's maybe not good to have the env be a data bag

so perhaps a separate map of key value options would be good?

the use case for flavors is mostly related to fetching dependencies

if you use a profile type task you end up fetching deps in two separate calls to set-env!

that causes problems with deps resolution

Some git guru here maybe can tell me how I can create a patch that differs from master, from a certain commit to another

Hmmm

the only think I can do, is to go to master and cherry pick merge my commits

which I guess is fine too

Shouldn't be needed

I just pushed the exactly same branch to github and diff is okay: https://github.com/boot-clj/boot/compare/arichiardi-sift-fix-test

oh let me try, without rebasing?

Yeah

No rebase needed, history is the same. GitHub is just confused for some reason.

Yeah, that fixed it.

right!

so I will work on the thread issue, because if you have 1000 tests at the moment you also create 1000 threads

then you can merge ok?

now I rebased and everything is ok

a question for @micha, future uses a https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool%28%29

Do you think we should bound the number of threads? The tests are kind of short-lived

I don't have enough experience in profiling this to take a decision

the other option is to have the classic bounded pool like clojure actors' pooledExecutor:

Executors.newFixedThreadPool(2 + Runtime.getRuntime().availableProcessors(), 
		createThreadFactory("clojure-agent-send-pool-%d", sendThreadPoolCounter));

yeah using infinite threads probably not good

you can do them in batches though

yes I was thinking about that

the simplest thing might be to make an executor pool

via the java stuff

yes then I need to replace it for future calls

or abandon future

does future take an executor as an optional argument?

let me check

nope

https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L6679

I could replace future with agent, which is more configurable

using send actually I don't need to do anything else

sweet, yeah

actually I do if I want it to be configurable, but for now I will just make it bounded

bounded? lol don't know if it's correct English

bounded, that's a thing

I have a weird error with the new version:

Assert failed: env :directories must be a set
                          (set? new)

are you setting :directories in any pod?

mmm no that I am aware of

investigating...

ops sorry

https://github.com/arichiardi/boot/blob/master/boot/core/src/boot/core.clj#L96 the (get-env :directories) returns nil

and the input is a string, so conj creates probably a list

the interesting question is why (get-env :directories) is nil

a change was merged today

that looks at boot.pod/env

instead of the atom

that's possibly the issue

uhm

does reverting that commit fix it?

will try

i bet that introduces a race condition

reverting g revert b55f444 -m 1

solves

ok cool

we can just revert that change for now

anyway if we're going to do that we'd want to do it completely and get rid of the atom

instead of just changing get-env

ok then, if you want to do it cleanly I guess @juhoteperi can rebase or something

that's good that we introduce testing 😉

we can have the revert commit in the history

ok then

will push that on my branch

awesome!

yeah regression testing is huge step forward

very exciting

@richiardiandrea: I'll push it to master, better than to include in non related branch

kk

I thought I ran Saapas using that change but maybe it just didn't trigger the problem

Or maybe I forgot to build Boot after changes

yeah the make install part is tricky, many times I forget that as well

i ran into problems working on a local snapshot version when there is a snapshot deployed to clojars

because of the way the different modules depend on each other

so for dev i'd set the version to 2.6.0

the pool is not a good solution for boot in boot I reckon, for some reason I my threads are locked, maybe batching is easier to implement for now

this warning for task redefinition is bothering me, can I ask you guys what was the concern when you introduced it?

in boot in boot (and therefore parallel testing) of course tasks will always be redefined and it might make sense to disable it

i like it because it can highlight issues between profile.boot/build.boot

but i also would support an env var disabling it

I was more thinking of util/*verbosity* but an env var is maybe a better idea

now you English speakers should help me with a name for this var 😄

i don't know what -v does - is it hooked to a var?

i guess it must be, since some how util/info etc see it

it is hooked to util/*verbosity*

it seems

yes it is

https://github.com/arichiardi/boot/blob/sift-fix-test/boot/pod/src/boot/util.clj#L31

maybe level 1 should print the task redef warnings?

with boot in boot you should have a fresh new boot.user namespace each time, so you shouldn't be seeing those warnings

we start with level 1, and up, so maybe we don't print it by default (level 1) and we start printing it from level 2 (`-v`) ?

it happens because we pass by -main I think:

clojure.core/require                                core.clj: 5832
                                 clojure.lang.RestFn.invoke                             RestFn.java:  421
                                          boot.user/eval108         boot.user852375673052143229.clj:   15
                                 clojure.lang.Compiler.eval                           Compiler.java: 6782
                                 clojure.lang.Compiler.load                           Compiler.java: 7227
                             clojure.lang.Compiler.loadFile                           Compiler.java: 7165
                                   clojure.lang.RT$3.invoke                                 RT.java:  319
                                         boot.main/-main/fn                                main.clj:  201
                                            boot.main/-main                                main.clj:  201

there should be a different boot.main too though

the newcore method should be making a new pod

ok will try to follow the chain

well the exception already gives me some hint:

clojure.core/require                                core.clj: 5832
                                 clojure.lang.RestFn.invoke                             RestFn.java:  421
                                          boot.user/eval108         boot.user538939168026557179.clj:   15
                                 clojure.lang.Compiler.eval                           Compiler.java: 6782
                                 clojure.lang.Compiler.load                           Compiler.java: 7227
                             clojure.lang.Compiler.loadFile                           Compiler.java: 7165
                                   clojure.lang.RT$3.invoke                                 RT.java:  319
                                         boot.main/-main/fn                                main.clj:  201
                                            boot.main/-main                                main.clj:  201
                                    clojure.lang.Var.invoke                                Var.java:  394
org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke             ClojureRuntimeShimImpl.java:  159
org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke             ClojureRuntimeShimImpl.java:  150
                                           boot.App.runBoot                                App.java:  399

maybe there is a bug in the way pods work?

maybe, the thing is, the core pod always calls boot.main/-main in boot in boot: https://github.com/arichiardi/boot/blob/sift-fix-test/boot/base/src/main/java/boot/App.java#L398

and this triggers the require

but you created that core pod, though, right?

so it should be a brand new boot.main/-main, a different one than the ones that ran before

my internet is ridiculously slow

https://github.com/arichiardi/boot/blob/sift-fix-test/boot/core/build.boot

how does this work? i don't see where runtests is coming from?

in https://github.com/arichiardi/boot/blob/sift-fix-test/boot/core/src/boot/task/built_in.clj#L900

runboot is called here: https://github.com/arichiardi/boot/blob/sift-fix-test/boot/core/src/boot/task/built_in.clj#L896

ah i see

for each command I have a runboot call

if each runboot creates a separate pod and no bugs, you are right, there should not be any warning