I'm sorry this is likely a very dumb question. How can I configure the color of the return values in the boot repl. I assume the answer has something to do with nRepl, but I'm not quite sure where to look or if there is a boot specific way of setting this for my account no matter which project I'm working on. My background color is dark grey and the blue result color is exceedingly difficult to read.

@binduwavell: this annoys me, too

the best thing i can recommend is boot -C repl

the colors are configured by REPLy

(the -C option to boot disables colored output)

Is there something like the whidbey lein plugin for boot?

@micha that is way better for now, thank you!

you can use whidbey with boot i think

Would be nice to have real color output though

one second, i'll see if it works

@micha can you point me at docs for how to use lein plugins with boot? I'm happy to give whidbey a shot.

you can't really use lein plugins with boot

you can ue the underlying functions etc

it's not clear to me exactly what the whidbey lein plugin is doing to nrepl and reply

but boot uses nrepl and reply too, so it should be possible

Did you see the following from their readme: "Internally, Whidbey reaches into nREPL to replace the default pr-values rendering middleware. See the history for more on the motivations and implementation details behind this project."

you can add nrepl middleware to the boot repl task if that's what you need to do

He has a nice article on what he did here: https://github.com/greglook/whidbey/blob/master/HISTORY.md

https://github.com/boot-clj/boot/wiki/Cider-REPL

Thanks @micha I hope I can figure out how to get these things to work together, would be super nice! Appreciate the pointer to the Cider-REPL doc...

if you can make it work i'd enjoy seeing how you did it

@micha of course!

I've just downloaded new boot.sh and it started doing

Downloading .

@jaen: Does the project you are working with have a boot.properties file which defines BOOT_VERSION?

No, this one doesn't.

I didn't create it yet

And this keeps repeating on each boot command, as if it couldn't download boot

Strange. If you don't have BOOT_VERSION defined it should use the latest version.

This didn't happen before I downloaded new boot.sh if that helps

Perhaps you should clear the boot temp dir? (~/.boot/cache)

Hm, when I added boot properties and specified 2.4.2 this stopped happening.

But funny it kept trying to redownload it each time with 2.0.0

Probably there is a old ~/.boot/cache/boot.properties file which points to 2.0.0

But redownloading sounds like a bug

The ~/.boot/cache/boot.properties points to 2.4.2 for me, but I imagine this was overwritten when I added the boot.properties to the project.

I don't think project boot.properties should have any effect on global boot.properties

What does boot -V say if you run it outside the project dir?

Downloading .
#
#Sun Nov 15 11:47:21 CET 2015
BOOT_CLOJURE_VERSION=1.6.0
BOOT_VERSION=2.4.2
#App version: 2.0.0

And the downloading thing keeps repeating on each invocation

Hmm the app version looks incorrect

I suggest removing or renaming ~/.boot/cache

Hmm, I've just notice I have a ~/.boot/boot.properties which pointed to 2.1.2. I've cleared the cache subdir, the lib subdir and put 2.4.2 in the aforementioned file and it stopped

Hm, is there something to set the env values that behaves like with-bindings so I can have the change scoped to single task only?

@jaen: unlike thread-local bindings, not all changes to the JVM can be "popped" back off the stack

like if you add dependencies to the classpath, there is no way to remove those jars from the classloaders they were loaded into

Right. What what I had in mind was :resource-paths - boot-immutant plugin seems to require sources in the resource paths, but that feels weird to put them there, so I wanted to scope it only to the task that requires it.

there is a with-env macro floating around somewhere

i can't find it at the moment

@jaen: Often it's the correct way to add Clj sources to resource-paths

@jaen: Boot terms source-paths and resource-paths are a bit different from Leiningen's terms. Source-paths means files that should be present in classpath but not present in the JAR (sources that are compiled, like cljs->js, java->class, AOT compiled clj->class) and resource-paths are files which should be present JAR like non-AOT clj

Ah, I see

i just added an exe task to https://github.com/adzerk-oss/boot-jar2bin

hope someone finds it useful!

you can create standalone *nix executables like boot aot pom uber jar bin --output-dir bin, and windows exe files like boot aot pom uber jar exe --output-dir bin (though the exe task requires launch4j and a little bit of additional configuration via task options)

it will also work with existing jar files, i.e. boot jar --file target/my-project-0.1.0.jar --output-dir bin, same for the exe task

@dave :thumbsup: 🚀

Any help with testing 2.5.0-SNAPSHOT would be greatly appreciated

@micha: I guess we should work out the push options before the next release

yeah totally

One solution would be to replace repo-map option with repo-username, repo-password, repo-passphrase

Not sure if other options make sense?

Or should be encourage people to set up separate deploy repositories (like bootlaces does) and not provide those options for push task?

Boot could even provide default deploy-clojars repository with sensible username and password default options

Btw. the changelog for 2.5.0 looks really good!

Fixes many problems I have encountered

i think we want some kind of merging behavior, perhaps

i like the repo map i think

There is merging behaviour currently

does it rely on the repo names, or urls?

names

maybe we should merge by url

or url regex

not sure

that would allow the project to define repos

and your local creds could apply to them

It makes sense to select the used repo by name in push task

totally

but when you have your creds file you want to associate password and stuff with the repo url i think

Hmm yeah

or at least use your own names there

maybe that's the best way?

then you could do the BOOT_REPO_USERNAME env var thing

Perhaps push task could use the similar logic to resolve-deps

deps?

how about this

https://github.com/boot-clj/boot/blob/master/boot/aether/src/boot/aether.clj#L134 this merges creds by url regex

we have a repositories.edn file, which the user uses to configure names and repo info

maybe...

we can then have other files that merge on top of that

the repositories,edn file is to associate names with repo configs

so you'd have {:clojars {:url "htps://...."}}

in repositories.edn, at minimum

That's the same data that's on boot env?

sort of

What's the benefit of moving it from env to edn file?

then you could have credentials.edn.asc or whatever

the credentials file would be merged on top of the repositories file

env vars merged on that

and system props

ok

How would that work with clojars where the creds should only be merged for deploy?

so when all the merging is done we have a database of repo configs

which we then index by url

so for each repo url we have info such as the name the user gave for it

the username, password etc

now suppose a project provides :repositories in via set-env!

suppose those are named like "snapshot" and "release"

like this

:repositories [["snapshot" {:url ""}]["releases" {:url ""}]]

when you do boot push -r snapshot

it would find the repo url in the env

and then it would be able to look that up in the index from the merged local stuff

and merge that on top of it

so you'd get usernames and passwords and whatever

and your own names wouldn't need to coincide with the ones in the project build.boot

The current creds file matches to repos by url regex

oh

So it would be possible to implement this without much changes

it seems like we don't need to change anything?

But the problem is that it must be defined somewhere if the repository needs credentials for download and/or deploy

clojars doesn't need credentials for downloading but needs creds for deploymed

datomic repo needs creds for downloading

does clojars fail if you give creds for downloading?

Not sure

Leiningen has separate repostory configurations for these. :repositories {"clojars" {:url "..."}}, :deploy-repositories {"clojars" {:url "..." :username :gpg :password :gpg}}

yeah i'm not sure that's a good idea

seems like the lazy solution

that's something you have complete control over via set-env!

like if you want to add some repos only for deploying you can do that in your deploy task

Yeah well as I mentioned, one solution would be to encourage using separate repositories for deploy repos

like deploy-clojars set up by bootlaces

hm

ok, so we currently have --repo-map for the push task

which does what the :deploy-repositories thing does

so that's good

i would say that problem is solved

the problem we have now is that the creds are by url, and you can't have different creds for pushing and pulling?

Also, there's a small problem though, repo-map has to be set up in the project but different users can have different preferences to where to retrieve the creds

i think that's correct behavior

you'd set up repo-map in your build.boot file

that ensures that the jars get pushed to the right place

Maybe one user wants to use creds from the file and other from env variables

But maybe we don't need to support this

Afaik leiningen doesn't support different creds for pushing and pulling

i think we should maybe even remove the :env :gpg etc stuff

And I don't remember seeing any issues about this

we should just check those places

and use the first that is found

i.e. system prop, env var, creds file

in that order

Currently those options are used to define when to use any creds

i can't imagine that using valid creds would cause something to fail

that would be pretty wacky

if you have valid creds it should be fine to use them

Testing now

One side-effect would be unnecessary gpg invocation any time dependencies are loaded

Though it should be memoized so it's ran only once per boot process

hm

yeah it would pop up the thing and you'd have to type in your passphrase

Yeah depending on your gpg conf

yeah

gpg-agent has a pretty short cache time by default, on ubuntu

I'm using gnome-keyring as ssh/gpg agent, it saves the password on keyring which is opened when I login

Though I would rather throw last part of gnome away and use something simpler, but gpg-agent is too horrible to use

lol i got rid of gnome completely

we don't want to support gpg agent though

i mean people needing to get that correctly configured to be able to use boot

We don't have to, as gpg binary does that

yeah but there are many ways it can be broken

i know, i've been there lol

Yeah, OS X setup was even worse than Ubuntu configuration

yeah so i think we can't assume that gpg-agent works

so i guess we do need to make something more complicated

The password entry GUI is horrible by default, "I won't let you access other programs or paste any text here because that would be insecure" :<

with some kind of push/pull specific configs

i brb one sec

Looks like clojars works if creds are used for downloading deps

I think the current solution is as good as or perhaps a bit better fit than Leiningen's (separate :deploy-repositories) so if can't come up with better solution we can release it

One could be to introduce some special keys to repository maps, like ["clojars" {:url "..." :deploy {:username :gpg, :password :gpg}}]] where :deploy value would be merged with toplevel when doing deploy and dropped when downloading deps

Could be acceptable as the repository maps aren't even now completely identical to aether presentation, because of the :gpg and :env special values

how about

{"" {:authenticate [:pull] :username ... :password ...}
 ...

actually what if we eval the credentials file

instead of read

this way you could build it however you need to

That requires gpg invocation, which we probably want to avoid for cases where it's not necessary

oh right

that means we want to separate the secret from the non secret

which means we could add BOOT_HOME/repositories.edn

and BOOT_HOME/credentials.edn.asc would be merged on top of that

that makes total sense to me

What would the first one contain?

it would contain the info about repos that isn't secret, liket his

maps with url regex and options about where to get the creds from?

{"" {:authenticate [:push]} ...}

and other repo config that isn't secret

Perhaps URL and such should still be set with set-env!

and the file only used for setting cred source

yeah i think we would want to merge

I'm not sure

the repositories.edn file would provide defaults

the project env and --repo-map would override that

and if :authentication is needed then we'd merge in creds by the various ways

creds file, env var, system prop

in reverse order lol

Or perhaps the repo defaults are read from the env, and then repositories.edn could overwrite or add values to those and it could use the same regex matching as creds file currently

Could also make sense to allow setting the same :authentication option or such from set-env

yes, i think it should use the same regex matching

but i think that per project things should always override global things

so i would say the repos.edn file should be just the defaults

and the project could override that in the set-env! or --repo-map

What about boot default repositories?

yeah we should write those out to the repos file

on first boot

And if the repos.edn is the default, it can't use regex matching as there is nothing to match against

sure it can

it matches against the concrete ones in the project env or the defaults

we'd get the set of active repos from the env or boot default

then we'd find matching repos.edn entries

merge the repos from the env on top of the ones found in repos.edn then

i think that would be fine, no?

Ah, yes I think so

i was thinking that repos.edn wouldn't add anything to your project

Yes makes sense

it's just a database of metadata and config for repos that might be pulled in

the env sets the available repos and stuff from repos.edn is merged into that, but values from env taking precedence

we could actually make it a program

eh, i guess no need

we could eval it at least, though

it wouldn't really change anything in the case where it's a static map

but you could put logic in there to figure things out if you needed to

like if you wanted to implement some other env var naming convention of your own

or something

2.5.0 is going to have some good stuff in it

so in the shower i realized something i think

perhaps we don't need all the special conventions of env vars and credentials files and all that

or repos.edn

we could perhaps use profile.boot for this

(set! boot.pod/*configure-repositories*
  (fn [repo-map authenticate?]
    (-> {"" {:name "clojars" :username (if authenticate? (get-creds ...))}}
    (merge repo-map))))

and tasks would call that function, perhaps?

we could of course make a function that gets creds etc