deraen: clojars should ignore creds if you are resolving deps, since you are only talking to nginx to get static files for that

Got the 2.5.0-RC working with Lein creds file:

(configure-repositories!
  (fn [m]
    (merge m (some (fn [[regex cred]]
                     (if (re-find regex (:url m))
                       cred))
                   (gpg-decrypt ( (System/getProperty "user.home") ".lein/credentials.clj.gpg") :as :edn)))))

I was a bit suspicious about calling repo-config-fn when repos are set instead of when credentials are used, but it seems to work fine

And Clojars does indeed work fine even if creds are provided for downloading deps

Hmh, running it always has some small runtime penalty. Because config fn and gpg-decrypt is always ran when calling set-env :repositories it always adds about 100ms to runtime, even when only running boot help

Hello people

I just downloaded the latest version of boot.sh (the one linked from https://github.com/boot-clj/boot)

and then I do boot -h I am getting this error:

any idea what I could be doing wrong?

TIA

@thomas: Probably you have old boot.properties file at /.boot or /.boot/cache

Delete it and boot should create new one when you next run it

thanks @juhoteperi that did the trick

@juhoteperi: yeah the 100ms isn't great, but it does simplify the whole thing considerably

also you can use tasks to get finer grained control

like profiles with different creds

Hmm, true

like maybe you have a push profile

if you call configure-repositories! in a task it will update repo configs

there's a watch on the atom that holds the fn

so you could have one fn for push and one for pull

did you see https://github.com/boot-clj/boot/commit/514595e0c6147515fdd6591d027fbff38c4c3ea4

what do you think?

so if i have that repo in my :repositories it'll look in the env vars and throw if not found

a nice thing about this whole thing is that it dispatches on url instead of name, so you won't acidentally send creds to non-https endpoints

I think it's quite confusing that get-env now does two different things

you don't think it's useful?

it can be useful but I think there should be separate functions for accesing Boot env and system env

i had a really hard time thinking of a name

Yeah

get-env was a terrible choice

in for the boot fn name

Also, instead of list destructuring I think it would be preferred to define multiple arities, it prevents some bad uses

how do you mean?

oh like more than the accepted number of arguments

(defn get-env ([] ...) ([k] (get-env k nil)) ([k not-found] ...))

yeah

👍

And the arglists will be more accurate

How about get-system-env? It's quite long but I think it would be better than get-env doing two things

Will probably be impossible or really hard to change this later if get-env is changed now

yeah

sys-env perhaps?

or maybe jvm-env?

Both are okay, I would maybe keep the get- prefix so it would match get-env

But if opinion is that get-env is bad name, maybe there is no need to match that name