Fork me on GitHub
#boot
<
2017-03-16
>
ag00:03:03

- I tried putting exactly as it says here: https://github.com/dgrnbrg/spyscope#boot

ag00:03:38

- to ~/.boot/profile.boot - then to build.boot

ag00:03:16

- I’ve tried changing the version

ag00:03:27

still getting java.lang.IllegalStateException: Attempting to call unbound fn: #’spyscope.core/print-log

hiredman00:03:04

given that, my guess would be you didn't do the (require 'spyscope.core)

hiredman00:03:01

did you get any kind of error when you did it?

ag00:03:56

does it matter if it’s in profile.boot or build.boot?

ag00:03:15

I’ve been trying both and still not working ;(

hiredman00:03:16

I would go with build.boot

hiredman00:03:24

what does (contains? @@#'clojure.core/*loaded-libs* 'spyscope.core) say?

micha00:03:05

when boot generates the boot.user namespace it pastes in the contents of your profile.boot followed by the contents of your build.boot

micha00:03:21

you can see this if you do boot -vb for example

micha00:03:40

that shows you the generated namespace that boot will evaluate when it runs

micha00:03:46

the unbound fn business seems like a regular clojure issue, not necessarily boot related

hiredman00:03:11

yeah, that is exactly what would happen if spyscope.core wasn't loaded

ag00:03:23

this is what’s happening

$> boot -vb

(ns boot.user
  (:use boot.core boot.util boot.task.built-in))

(set-env! :dependencies #(conj % '[spyscope "0.1.5"]))

(require '[spyscope.core])

(load-data-readers!)

;; end global profile

;; start boot script

micha00:03:03

i will try that

ag00:03:09

does it mean that next `set-env! is reseting depenencies?

hiredman00:03:32

and then what do you run that actually throws that error?

hiredman00:03:42

I bet you are running a task that runs in another pod or something

hiredman00:03:52

which doesn't have spyscope.core loaded

ag00:03:37

I just have a piece of code with #spy/p in a file and trying to start repl - it won’t compile

ag00:03:37

I don’t really give shit about spyscope - I was managing without it so far (mostly doing things in CLJS) this lib seems to be of much importance to my colleague though.

hiredman00:03:03

I think the repl runs in another pod, try putting the require in the source file

micha00:03:27

@hiredman the repl server runs in the core pod by default, so that's ok

micha00:03:38

but i agree that it sounds like an issue with pods somehow

micha00:03:51

the repl client does run in a different pod

micha00:03:56

the REPLy part

micha00:03:08

but it talks to the nREPL server in the core pod

micha00:03:28

i think i found something

micha00:03:52

it looks like it's working

ag00:03:35

it works when you require it in repl, it won’t compile files containing #spy/p

ag00:03:44

is that how it suppose to work?

ag00:03:10

does it work the same way in lein? I don’t even remember now

micha00:03:10

so you're saying if i make a namespace that uses that #spy/p thing it will not compile?

micha00:03:23

ok i will test one sec

ag00:03:38

No reader function for tag spy/p
    data: {:file "finops_admin/db.clj", :line 17}

micha00:03:19

so in the same session i did this

micha00:03:40

where the foop.barp namespace is this:

ag00:03:54

Micha, it works if you initially bot repl and then require namespaces, etc. but if the file contains #spy/p it won’t even let you run boot - won’t compile

micha00:03:11

the file ^^ does contain that

ag00:03:37

again: you are requiring file in a repl that already started. If you have initially #spy/p shit in namespaces it won’t compile

micha00:03:23

i don't follow

micha00:03:36

i do have #spy/p shit in a namespace

micha00:03:42

and i can run boot repl

micha00:03:47

without anything crashing

micha00:03:12

the only thing you need to make sure of is that you don't try to compile those namespaces before you do load-data-readers!

ag00:03:23

1) kill the repl 2) add spy/p shit to one of the files 3) start the repl. does it work?

ag00:03:38

so how do I ensure then that no task would run without running (load-data-readers)?

micha00:03:53

ah this is interesting

micha00:03:43

the -s src -d spyscope options there is just doing (set-env! :dependencies '[[spyscope "RELEASE"]] :source-paths #{"src"})

micha00:03:51

so i don't need to make a build.boot file

micha00:03:47

you do need to do (require 'spyscope.core) before trying to compile a file with #spy/p in it

ag00:03:00

I am doing that

micha00:03:22

ok i will make a demo project, see if it works for you

micha00:03:54

you can try adding :require [spyscope.core] in the namespace that has the tagged literals in it

ag00:03:25

oh, shit,,, I think I see what’s happening.

ag00:03:57

the namespace with #spy/p is required through other ns that is required in build.boot

ag00:03:14

and that does not compile

micha00:03:03

you tried putting the (require 'spyscope.core) and (load-data-readers!) in your profile.boot?

micha00:03:21

that will be evaluated before the contents of your build.boot file

ag00:03:20

I did, but for whatever reason it didn’t work. hold on.. I think If I put:

(require '[spyscope.core])
(load-data-readers!)
before other requires it may do the trick

ag00:03:40

that I think did the trick with the repl, but:

micha00:03:01

this is what i have

ag00:03:46

hold on… I promise I’m won’t be whining for much longer 😉

ag00:03:23

the ns I put #spy/p is required in tests, and when I run boot test it throws something else:

ag00:03:38

Attempting to call unbound fn: #‘spyscope.core/print-log

ag00:03:04

I really hate that lib

ag00:03:06

honestly

micha00:03:27

i think in the tests you can fix that issue by requiring spyscope.core

micha00:03:36

in the same namespace where you get that error

micha00:03:12

i am not a fan of tagged literals in general, personally

micha00:03:10

since you got the error referring to #'spyscope.core/print-log that means the tagged literals are at least working properly in the reader

micha00:03:43

like #spy/p is being properly transformed into (spyscope.core/print-log ...)

micha00:03:24

are you using boot-test?

ag00:03:43

adzerk.boot-test

micha00:03:15

did you see the -S/`--startup`/`:startup` option?

micha00:03:31

i think you can use that to do (require 'spyscope.core)

ag00:03:35

is it for the test task?

ag00:03:01

does it mean I can stick it into task-options!?

micha00:03:14

you can use that option to call a function when boot-test craetes its pods

micha00:03:21

before it does other stuff

micha00:03:43

looks like it takes a set of symbols

micha00:03:01

so the symbols should resolve to functions i suppose

micha00:03:57

ah nevermind

ag00:03:00

:requires?

micha00:03:46

yeah that looks promising

ag00:03:52

Attempting to call unbound fn: #‘spyscope.core/print-log, damn it!

ag00:03:24

alright I think I get it, I’ll dig some more. Micha thank you so much. really appreciate your help

micha00:03:46

hope it works out

ag00:03:50

I hope I can convince my guys to keep boot

ag00:03:06

I really don’t want to convert everything back to lein

micha00:03:21

there is one more option

micha00:03:31

there is the boot-shim.clj file

ag00:03:45

right, I think I heard something about that thing

ag01:03:54

oh wow… just checked it out - it scared the shit out of me. I’m scared of boot-shim.clj

micha01:03:46

hm it might be a pain to use it for this purpose

micha01:03:18

have you tried boot alt test?

ag01:03:42

eh? what’s that… never heard

micha01:03:00

boot-test makes new pods for each test run

micha01:03:13

but that is what makes the data readers situation so frustrating

micha01:03:27

boot-alt-test i think won't have that issue

ag01:03:41

you know what I think :requires option just worked

ag01:03:17

once again: I can’t thank you enough!

micha01:03:43

awesome! good luck 🙂

kentnl01:03:15

is there a simpler way to (push) without all the frills? I'm hoping if I can side-step all the indirection I can at least do something crude that works

richiardiandrea02:03:25

@kentnl maybe you can use bootlaces? I haven't had any problem with it and if it cannot find gpg stuff it will prompt

richiardiandrea02:03:52

Also maybe that part could actually go into core

kentnl03:03:50

Looking at the code, I see its actually a wrapper for push

kentnl03:03:03

My problem was even calling push directly with a :repo-map value, with the :username and :password fields coded in directly with (System/get-env ... inside the appropriate entries, clojars still wasn't getting the username values.

kentnl03:03:08

It boggles my mind why.

kentnl03:03:39

that's why I want something less featured, because I looked at the mechanics of push and its internals made me want to stop living.

kentnl03:03:49

I can't debug that 😞

kentnl03:03:37

I can't tell if I was even passing the data correctly, or if it was in the right format, nothing clarified things for me.

richiardiandrea03:03:22

Yes the repo map need documentation, there is an issue open for that and I banged my head on it as well

kentnl03:03:27

The wiki is very bad here. Like the (set-env! :repositories example tends to break resolving [clojure , entirely.

richiardiandrea03:03:06

@kentnl feel free to give a bit of an improvement 😉 We can all profit from this small tweaks, in the meantime this worked for me: https://github.com/elasticpath/rest-resource-viz/blob/master/build.boot#L187

kentnl03:03:42

And with regards to configure-repositories, how can I even tell its working as expected?

kentnl03:03:07

My testing seems to indicate for some reason, its getting "lost"

kentnl03:03:37

( I sidestepped it entirely and it didn't fix the problem either, but my testing indicated it was faulting in 2 different places )

richiardiandrea03:03:51

Didn't debug that, but you see, had I documented it right away, you would not have spent time there... sorry about that!

kentnl03:03:56

Actually, this will help, is there a sensible way I can mock out the HTTP layer here and just get push() to end up invoking a dummy function that does nothing but fail?

kentnl03:03:30

I just want to have a sure fire way to see what's going on without needing to have an SSL-stripping MITM 😛

richiardiandrea03:03:48

Uhm, boot uses pomegranate so it is hard to mock

kentnl03:03:05

might just have to set up a fake HTTP sever ...

jeeq05:03:15

this is a super noob question but could anybody tell me why my BOOT_CLOJURE_VERSION always goes to 1.7.0 instead of 1.8.0? I have tried deleting .boot and running boot -u (boot -U also uses 1.7.0)

qqq06:03:15

@jeeq: try putting a boot.properties file in the same dir as your build.boot file

qqq06:03:23

then hardcode BOOT_CLOJURE_VERSION in your boot.properties file

micha15:03:55

@jeeq also you might check what's in your ~/.boot/boot.properties

micha15:03:03

that sets the system-wide default for you

micha15:03:17

but it is always good practice to do what @qqq said above

micha15:03:38

and commit that boot.properties file with the project repo

micha15:03:53

that way you can pin the build to the version of boot you want to support

ag19:03:51

so there’s really no way to override :source-paths for adzerk/boot-test ?

ag19:03:41

so this:

(deftask override [] (set-env! :source-paths (fn [_] #{"ui_tests/clj"})))

(deftask run-tests []
  (comp
    (override)
    (test)))
doesn’t seem to work. although if instead of (test) I run (:source-paths (get-env)) it shows it correct, but (test) seem to be ignoring that

miikka19:03:21

I thought that should work

miikka19:03:12

I'm now reading boot-test source and oh no @ the junit reporter code 😄

miikka19:03:25

composing reporters is so awkward

micha19:03:09

the override task there is not middleware

micha19:03:16

so that would be an issue

ag19:03:32

you mean it’s missing identity?

micha19:03:37

but it also wouldn't do what you want

micha19:03:46

it needs to return middleware

micha19:03:30

but changing source paths is sort of cumbersome in boot currently

micha19:03:13

pods are generally constructed based on the environment in which the pods are created

micha19:03:42

you can alter the way boot-test creates its pods to give you more control

ag19:03:20

how? I wish boot-test would allow me to specify paths and not namespaces to include

micha19:03:37

i mean by hacking the boot-test code

micha19:03:25

usually it's fine to have the same source paths for test and whatever else

ag19:03:11

usually it is - not in my case - I have unit tests and I have e2e tests, I need to run them separately

micha19:03:41

why can't you do that?

micha19:03:51

you could use two instances of the test task or something

micha19:03:20

also boot-test does have filters you can use to restrict the namespaces under test

ag19:03:46

I have test/clj and test/cljs and I also have ui_test/clj I need to force it to run tests only in ui_test/clj

ag19:03:45

restricting namespaces is tricky - if you restrict to namespaces of to use only ^.*ui-tests.*$, they can’t seem to be able to require anything from src/clj

micha19:03:16

you tried the --filters option?

ag20:03:10

The set of expressions to use to filter namespaces. what does it even mean?

ag20:03:02

oh hold on… I think :include worked

ag20:03:52

let me play with it some more… I’ll come back later, to continue complaining about my life

micha20:03:41

there is more info in the docstring boot test -h

micha20:03:56

they're expressions, with % bound to the var in question

micha20:03:11

so you can filter based on the name or whatever

micha20:03:45

(test :filters #{'(.startsWith (str (:ns (meta %))) "ui_test")} ...

laforge4920:03:02

How can I just run some code in a task? Here's my latest attempt:

laforge4920:03:51

I get this: java.lang.ClassNotFoundException: q.s1

laforge4920:03:01

Do I need a shift or something?

hiredman21:03:50

what are you trying to achieve?

hiredman21:03:28

clojure does symbol resolution as part of compilation, so the symbol resolution fails when it referes to something that doesn't exist until after aot has run

laforge4921:03:28

So how do I invoke something that exists only after the aot is run?

hiredman21:03:55

the other thing is you likely don't need to aot at all

hiredman21:03:03

you can just load the clojure code and call it

laforge4921:03:13

by doing what?

laforge4921:03:31

--I feel like I'm missing something obvious.

hiredman21:03:39

(deftask s1
  "run s1"
  []
  (with-pass-thru _
    (eval '(do
             (require 'q.s1)
             (q.s1/-main)))))

hiredman21:03:39

a lot of people aot compile unnecessarily because they don't seem to know how else to start a clojure program, I have a little write up https://github.com/hiredman/clojure-site/blob/df56aef005d5d867213a51c2d3bbec5a86b0acad/content/guides/running_a_clojure_program.adoc

hiredman21:03:37

aot compilation can be a source of a lot of pain, so it is a drag to see people doing it when they don't need to

kentnl21:03:55

I tried to use a custom URL in my repo-map, but now I'll I get is:

org.sonatype.aether.transfer.NoRepositoryConnectorException: No connector available to access repository hacks () of type default using the available factories FileRepositoryConnectorFactory, WagonRepositoryConnectorFactory
    repository: #object[org.sonatype.aether.repository.RemoteRepository 0x275fe372 "hacks (, releases+snapshots)"]
         org.sonatype.aether.deployment.DeploymentException: Failed to deploy artifacts/metadata: No connector available to access repository hacks () of type default using the available factories FileRepositoryConnectorFactory, WagonRepositoryConnectorFactory
                                 clojure.lang.ExceptionInfo: Failed to deploy artifacts/metadata: No connector available to access repository hacks () of type default using the available factories FileRepositoryConnectorFactory, WagonRepositoryConnectorFactory

kentnl21:03:23

Sound familiar to anyone?

kentnl21:03:26

I tried reading the related aether java code and almost died from excessive wtfs per minute

kentnl21:03:24

oh well, found hacks around it. Repo-map documentation being confusing and apparently having the values in it entirely ignored aren't helping.

kentnl21:03:13

Desperately needs clear validation and error handling