Fork me on GitHub
#boot
<
2016-09-07
>
chris_johnson00:09:43

hopefully-not-too-boneheaded question about boot-logservice: I want to use it with clojure.tools.logging/with-logs to capture off the stdout output of a process I don’t control (lives in a closed-source jar) but with-logs wants me to provide a namespace from which to pretend to log, and my core namespace isn’t visible from within the log-service pod

chris_johnson00:09:20

how can I either make it visible there, or divine the log-service pod’s *ns* from my core ns so as to pass it uh

chris_johnson00:09:27

“back in” to with-logs?

alandipert02:09:48

@chris_johnson hm, that doesnt' just work? looks like it takes ns as an arg, which is a symbol iirc

chris_johnson02:09:02

No, it yields the kind of ClassNotFoundException you'd see if you tried to run something that you had eval'd in a REPL but not built anywhere

alandipert03:09:23

ok, i see the problem now too

chris_johnson03:09:29

There's a problem? I was seriously just hoping for someone smarter and more experienced than me to tell me what I did wrong! 😄

alandipert03:09:56

i did (boot (repl :pod "adzerk.boot-logservice")) and now i'm in the pod poking around

chris_johnson03:09:41

Let me see if anything helpful shows up in my stack trace

chris_johnson03:09:31

[adzerk.boot_logservice$slf4j_service_factory_factory$reify$reify__1512 write_BANG_ boot_logservice.clj 41] ?

chris_johnson03:09:51

scanned right past it before because I didn’t think I was bug hunting

alandipert03:09:01

that's the one

alandipert03:09:15

and we see pod-eval/eval so we know it's in the with-eval-in block

alandipert03:09:38

(get-logger* ~(str logger-ns)) is the suspicious line

alandipert03:09:52

logger-ns is a string there, and we're in the with-eval-in block so the ~ should splice it in

alandipert03:09:23

the exception is acting like the generated code is (get-logger* foo.bar) instead of (get-logger* "foo.bar") which is what i would expect from a call like (log/with-log foo.bar ...)

chris_johnson03:09:56

I’m actually sort of following this - I spent a lot of time last week poring over this code before I realized that my Hiccup-fu was weak and was making a slightly-incorrect logback.xml

alandipert03:09:26

yeah basically it implements a logger for tools.logging purposes, but the implementation defers to stuff running in a pod

chris_johnson03:09:37

yeah, it’s really elegant

alandipert03:09:53

now, if it would work correctly lol

chris_johnson03:09:01

I like it a lot, and not just because it saves me hours of reading (boot (show “-p”))

chris_johnson03:09:54

so, I’m not as experienced as I’d like to be with debugging the internals of a function call going awry - would it be helpful to you if I pastebin’d up the core.clj where this is all happening?

alandipert03:09:10

na, i think i can reproduce the problem OK

alandipert03:09:13

thanks though

alandipert03:09:44

i have to go shortly but i'll spend a few more minutes on it, if no fruit, perhaps yuo can make a ticket and we can dive in later

chris_johnson03:09:46

I’d be happy to, it will give me practice boiling a problem down to a minimal repro case, for which I would be grateful

alandipert03:09:02

sure, that would be handy

alandipert04:09:06

thank you kindly!

alandipert04:09:14

i think i fixed it - i pushed 1.2.0, can you give it a try?

alandipert04:09:58

i think it's a boot bug but i can't reliably reproduce, will try more tomorrow

chris_johnson04:09:56

@alandipert - indeed, that seems to work! I updated the dependency to 1.2.0 in the minimal-repro project, restarted the REPL, and now I get logging to nrepl-server instead of a stack trace.

chris_johnson04:09:23

I will plug 1.2.0 into my larger project and report back if there are any problems there, but I think you did fix it. 😄

alandipert04:09:52

good to hear

flyboarder06:09:21

Git commands for boot, and workflows! https://github.com/degree9/boot-semgit

pseud10:09:40

Looking for an example on how I should add development-only dependencies - I know that deftask + set-env! can be used to customize an environment, but is that the way to go ? What to people do ?

martinklepsch11:09:16

@pseud usually just adding them with :scope "test" is a good option as well

pseud11:09:33

@martinklepsch is that sufficient ? how does that later work when I publish a jar and such ? (thinking of lein and their profiles, here)

agile_geek11:09:28

@pseud anything scoped as test would be used to compile code on test directory tree and on the classpath for test goals executed by lein but not packaged in a jar or war.

martinklepsch11:09:59

@pseud it depends on what your goals are 🙂 :scope "test"dependencies are not transitive so when your project is used as a dependency your development dependencies won't leak

pseud11:09:14

exactly what I needed to know - that seems super. Wow.. To think, lein was a radical simplification of the hell that is ant and maven.. And boot a radical simplification of that.. Everything is relative indeed 😛

martinklepsch11:09:57

when using set-env! in a task you can avoid them showing up in pom.xml as test dependencies but this may cause differences in dependency resolution during dev/test compared to prod

dominicm11:09:57

@martinklepsch Would a dev task which adds the deps be better?

dominicm11:09:41

That way, it won't even get loaded during testing (not additionally)

pseud11:09:06

@dominicm that’s what I looked into, but I can’t quite figure out how to do that. At least I can’t setup the dev environment in one task and then use that task in another

martinklepsch11:09:29

@dominicm it may affect dependency resolution so you need to be aware that there might be different versions running in dev vs. prod

martinklepsch11:09:01

(which is something you usually want to avoid 🙂 )

dominicm11:09:15

@martinklepsch Isn't that a problem anyway? I use the show pedantic task as part of my pipeline

dominicm11:09:10

@pseud You can put the set-env! at the top of another task as normal. You need to return identity if it's the last statement in the task.

martinklepsch11:09:07

> Isn't that a problem anyway? I use the show pedantic task as part of my pipeline It's a problem when you change dependencies (versions or set-env!) as long as they're stable, resolution should be stable as well no?

pseud11:09:18

@dominicm interesting, will write that down for later experimentation 🙂

dominicm11:09:52

@martinklepsch No idea if it would be stable if you used the test scope either though.

dominicm11:09:38

You would hope, but if it's not pulled in outside the test scope, then the transitive deps would be different there too, no?

dominicm11:09:46

This is more of a question than a statement.

martinklepsch11:09:07

@dominicm riiiight... I now think maybe my previous statements were based on the assumption that all transitive deps+versions are listed in pom.xml which isn't the case I think

martinklepsch11:09:29

though in the context of an application that will never be a dependency itself that might be different? (i.e. uberjar contents are determined at build time including effects of :scope "test" on resolution?)

dominicm11:09:21

@martinklepsch What effect does :scope "test" have on transitive deps during an uberjar? Are transitive deps of a test scope still included in a non-test scope (e.g. building an uberjar)?

dominicm11:09:45

I think I just said the same thing twice, in different ways.

martinklepsch11:09:01

I think the dependencies might not be included but overall dependency resolution is affected

martinklepsch11:09:34

(i.e. they're loaded by maven but might not end up in the artifact)

martinklepsch11:09:05

I'm guessing a lot here so probably we should test this or something

dominicm11:09:24

Yeah, I wondered if maven was smart enough to do that. We should absolutely test it.

martinklepsch11:09:51

We could collaborate on a "Dealing with Dependencies in Clojure" guide 😄

agile_geek11:09:11

@dominicm I'm 99% certain Maven would not include transitive deps in an uberjar (or any packaged artifact) if they were only in the test tree and in test scope.

agile_geek11:09:20

When I've built Java projects packaged as jar's or war's using maven and checked dependencies in built artifact this has been the case.

dominicm11:09:20

@agile_geek But what if your test tree, included a newer/different version than something in your non-test tree. What would happen then?

martinklepsch11:09:04

@dominicm can you list the same dependency twice?

agile_geek11:09:04

@dominicm I think it's non-deterministic which version would be loaded in test phase but only the version in the 'production' version would be packaged (assuming it's compiled scope and not provided)

agile_geek11:09:02

I've been caught out other way...compiled production code using a dependency only in test scope and the build runs but the packaged artifact fails with class not found at runtime.

dominicm11:09:32

@martinklepsch I'm thinking of a transitive dependency coming from a different dependency, that's only in your test tree. Not two top-level dependencies, one scoped to test, sorry.

agile_geek11:09:12

@martinklepsch definitely can happen transitively but yes you can list same dependency twice in a pom in maven, most often when parent poms are involved.

agile_geek11:09:10

I can't remember but think that maven loads the first version it finds...but don't quote me

dominicm11:09:52

I'm sort of thinking in terms of sod's law: if it can happen, it will happen.

agile_geek11:09:13

Different versions of dependencies happen all time in mvn in Java projects.

agile_geek11:09:53

I spent the last two weeks of my last contract trying to debug this exact problem!

dominicm11:09:20

@agile_geek Youch 😞

agile_geek11:09:45

@dominicm I wouldn't have minded but ran out of time without solving it!

dominicm11:09:37

@martinklepsch so I guess a good way to prevent dependencies from your development environment causing your tests to mysteriously pass, but your uberjar to fail, would be to put them in a dev task.

dominicm11:09:52

Boot tasks are pretty good at this usually, because of pods.

agile_geek11:09:57

no way to test locally as problem only happened when deployed in WAS and we didn't have local licenses for Websphere and could only deploy twice a day to a test environment. Ended up removing about 60% of the dependencies as they were not required. Copy and paste dependency management when project started!

dominicm11:09:39

@agile_geek Doesn't sound very agile 😉 where was your influence? 😛

martinklepsch11:09:48

> so I guess a good way to prevent dependencies from your development environment causing your tests to mysteriously pass, but your uberjar to fail, would be to put them in a dev task. but in this case won't you have a different set of deps for dev and prod potentially causing trouble?

agile_geek11:09:24

@dominicm main reason for not renewing contract.

martinklepsch11:09:26

@agile_geek have you seen the way @stuarthalloway et al handle dependencies?

dominicm11:09:30

@martinklepsch They're different with the test scope anyway. Or that's what I thought @agile_geek said 😛

agile_geek11:09:01

@martinklepsch I think I watched a talk @stuarthalloway did on this.

martinklepsch11:09:33

@dominicm are you coming to ClojuTRE btw?

agile_geek11:09:58

@martinklepsch @dominicm test scope will load dependencies in app class loader for test and non test scopes but only package compile scoped to jars so diff versions of same jars would be loaded non-deterministically on class path.

dominicm11:09:53

@martinklepsch Not this year unfortunately.

dominicm11:09:45

@agile_geek I'm afraid I still don't fully understand that. Can I try with an example, and ask you questions about it? My app (APP) depends on A and B (B is in test scope) A depends on B v1 B from APP is v2 (in test scope)

dominicm11:09:46

My example is bad. Editing it

dominicm12:09:24

Trying again: 1) When I run my tests, would B be v2, because it is declared top level explicitly? 2) When I build my uberjar, would B be v1, because the top level B is in test scope?

agile_geek12:09:07

@dominicm sorry, crappy coffee shop wifi dropped!

agile_geek12:09:51

If B dependency is in both test scope and compile scope (transitively) then I suspect the version of B you would get in test phase would be undetermined. However, the version of B packaged would be that transitively referenced by library in compile scope.

agile_geek12:09:37

If B is explicitly in both test and compile scope at different versions then same I think the version you'd run against in test scope would be whichever was last loaded (not sure which that would be) but only the version referenced in 'compiled' scope would be packaged (not the version test scoped)

dominicm12:09:38

@agile_geek I thought so, I just wanted to confirm my understanding. This has somewhat scary implications for development tools right?

agile_geek12:09:23

Like I said just 2 weeks ago was trying to untangle dependency hell - WAR packaged and run in Jetty worked, same artifact deployed in Websphere App Server on same JVM version failed with missing class!

dominicm12:09:06

Because somebody was depending on that test scope you think?

dominicm12:09:25

(or some other scope not present when packaged)

agile_geek12:09:30

The class missing is present in rt.jar which is in the bootstrap class loader (highest priority and MUST be on classpath)!

agile_geek12:09:05

Never got to the bottom of it but some weirdness in WAS classloader order and transitive deps in pom (must have been in compile or provided scope as the 'packaged' artifact ran in one env and failed in other)

alexyakushev12:09:12

Can anyone help? 🙂

alexyakushev12:09:37

@dominicm: Thank you. This enumerates the scopes, which is already nice; but it is still not clear which scopes Boot applies during which tasks.

dominicm12:09:29

@alexyakushev I'd be interested to know too!

agile_geek12:09:21

@alexyakushev @dominicm I guess to understand that you'd need a mapping of boot tasks to maven goals and phases used by each task.

dominicm13:09:05

@martinklepsch Boot pulls in :scope "test" dependencies into your uberjar!

pseud13:09:37

Have a small problem, if I want a fixed nrepl port - cljs-repl has an example like so (cljs-repl {:nrepl-opts {:port 9000}}) — however, sticking that in a composition won’t work, something about attempting to convert a persistentarraymap to a charsequence.

dominicm13:09:02

@pseud: Does it work as:

(deftask foo
   []
   (cljs-repl {:nrepl-opts {:port 9000}}))

dominicm13:09:04

That example looks wrong now I'm looking at it. Try: (cljs-repl :nrepl-opts {:port 9000})

micha13:09:48

@dominicm @alexyakushev boot doesn't have any knowledge of scopes itself

pseud13:09:11

@dominicm yup ex 2 works, trying that

micha13:09:22

scopes are respected during dependency resolution by the Aether library, which is what boot uses to fetch maven deps

dominicm13:09:24

@pseud boot-cljs-repl would appreciate that fix to their readme.

micha13:09:49

basically it boils down to three scopes that you care about: compile, test, and possibly provided

micha13:09:59

compile is the default

micha13:09:49

when you make a pom from your project, which is needed when you upload a jar to a maven repo, the scopes are annotated in its dependencies section

pseud13:09:53

dominicm: you’re right about that, get on it, will ya ? 😛 Just kidding, I’ll look into it

pseud13:09:17

Even better 😄

micha13:09:17

the sole purpose of the scopes as far as boot is concerned are to establish a separation of transitive and nontransitive dependencies

micha13:09:01

the dependencies in your pom that are marked test or provided scope will not be visible to aether when another project uses your project as a dependency

micha13:09:21

the ones with compile scope will be pulled in transitively

micha13:09:50

boot does not (by default) include dependencies with test scope in uberjars

micha13:09:03

you can adjust this with a command line option

dominicm13:09:16

@micha I have an example that seems to show otherwise... :s

micha13:09:02

By default, entries from dependencies with the following scopes will be
copied to the fileset: compile, runtime, and provided. The --include-scope
and --exclude-scope options may be used to add or remove scope(s) from this
set.

dominicm13:09:00

(set-env!
  :source-paths #{"src"}
  :dependencies '[[org.clojure/clojure "1.8.0"]
                  [enlive "1.1.2" :scope "test"]])

(deftask build
  "Builds an uberjar of this project that can be run with java -jar"
  []
  (comp
   (aot :namespace #{'app.main})
   (pom :project 'app
        :version "1.0.0")
   (uber)
   (jar :main 'app.main)
   (sift :include #{#"project.jar"})
   (target)))
This compiles, against a namespace that requires in enlive. I don't think it should:
;; src/app/main.clj
(ns app.main
  (:gen-class)
  (:require [net.cgrand.reload :as reload]))

(defn foo
  []
  (println reload/auto-reload))

(defn -main
  [& args]
  (foo))

micha13:09:52

oh it's totally possible that clojure's compile function pulls them in

micha13:09:04

that's a completely different issue though

micha13:09:20

i highly recommend avoiding the use of aot like that

alandipert13:09:20

yeah, the AOT is happening at compile-time in the presence of the lib, which creates .class files, which end up in your uberjar

micha13:09:30

and using an "aot shim" instead

micha13:09:39

to defer compilation to runtime

micha13:09:01

but then you get runtime exceptions if your code in the uberjar really does depend on the dependencies with test scope

micha13:09:36

when i do aot for a jar, the namespace i AOT compile has no compile-time references to any other namespace

alandipert13:09:46

oh yeah, lemme fix that up with a java shim

micha13:09:59

it must use require and resolve at runtime

alandipert13:09:03

PRs neglecte^D err accepted

micha13:09:09

that way you avoid these kinds of tricky AOT problems

dominicm13:09:31

@micha Is this why many projects do some kind of funkage with eval in their (-main)?

micha13:09:46

usually like

(ns app.main-class
  (:gen-class))

(defn -main [& args]
  (require 'app.main)
  (apply (resolve 'app.main/-main) args))

micha13:09:03

we should have a task that just generates that

dominicm13:09:06

Yeah ^^. What effect does AOT have in that scenario?

micha13:09:14

it has no effect, really

micha13:09:19

other than creating the stub class

dominicm13:09:26

Seems borderline pointless.

micha13:09:33

it doesn't do any transitive compilation, which is what i want to achieve

micha13:09:59

it's AOT compiling the minimum possible thing that will still work with the java classloader

micha13:09:12

all the rest is done dynamically by clojure

micha13:09:46

imho it's worse than pointless to AOT compile vast swaths of clojure namespaces just to get a class that can be used as the Main of a jar 🙂

micha14:09:31

aot has many ways to go wrong, you can waste a lot of time debugging it

dominicm14:09:34

I thought AOTing them all was for performance.

micha14:09:59

well if you're on that train then you need to be aware that you're tinkering in perfland

micha14:09:10

and expect to need to spend time debugging things

micha14:09:19

clojure wasn't meant to be AOT compiled

micha14:09:40

like org.clojure/clojure jar isn't AOT compiled

dominicm14:09:38

Fair enough. I don't really care that much about the performance personally. I just thought it was a free feature toggle.

martinklepsch14:09:25

"free feature toggle" 😂

dominicm14:09:26

So AOT exists solely for making a main class, and Clojure projects don't want AOT at their dependencies. I need to make a patch to edge.

micha14:09:46

i just took a look in clojure.jar

micha14:09:53

there are .class files in there all over town

micha14:09:56

now i am confused

dominicm14:09:13

So Clojure is AOT'd? Plot thickens!

micha14:09:23

boot itself is AOT for performance

micha14:09:37

but it does cause weird problems

martinklepsch14:09:10

Aren't their different jars for clojure, one AOTd the other not?

dominicm14:09:27

@micha What kind of problems?

micha14:09:45

the namespaces are evaluated in the compilation process

dominicm14:09:01

@micha (launch-nuclear-missiles)

micha14:09:04

so top level forms must be wrapped in delay etc when they would perform side effects at compile time

micha14:09:44

also the generated bytecode compatibility becomes an issue at some point

micha14:09:53

so like i AOT with java 1.7

micha14:09:10

if i do it with 1.8 for instance, boot doesn't work on java 1.7

dominicm14:09:27

So if you avoided top level forms, you'd be okay though? Or are there innumerable problems. Yeah, I think that's a general JVM problem, I've seen jars which have had complaints about wanting compilation to go back (compiled for 1.8, they used 1.7, or whatever)

micha14:09:43

yeah and the error message is very mysterious

micha14:09:58

it will say like "incompatible minor version 5.1" or something

dominicm14:09:10

Yeah, I know that error.

micha14:09:17

i just recognized the regex pattern in my mind and know what it means

micha14:09:58

also the perf stuff with AOT is i think just startup

micha14:09:09

like if you have a service you won't get a lot of benefit i don't think

micha14:09:18

boot we want to start as fast as possible

dominicm14:09:20

So, back in my days fiddling with java, I compiled a jar or two, and you could specify the JDK to target.

dominicm14:09:28

In the IDE.

micha14:09:34

eliminating compilation of namespaces shaves like 700ms off the startup time

micha14:09:58

some namespaces are mysteriously expensive to compile

micha14:09:11

like the nrepl server namespace takes like 4 sec to require

micha14:09:45

yeah there are ways to tell jave to cross compile, but i couldn't figure out how to do it reliably

micha14:09:00

and rather than tinker with configuration i just use java 1.7 when i build it

micha14:09:27

my patience is limited when there is a stupid way to do it that always works

dominicm14:09:41

Lol. Harder if you have developers compiling on their machines though I guess?

micha14:09:06

continuous integration service is i guess the answer?

dominicm14:09:29

CI is just so webscale 🙂

micha14:09:48

yeah it generally annoys me too

dominicm14:09:19

I've used deploy boxes before, and wondered why. But this would be a good reason.

micha14:09:28

you can do docker in travis-ci, which is pretty simple

micha14:09:43

my travis yml file has 3 lines now for the project i was working on yesterday

micha14:09:02

sudo: required

services:
  - docker

before_install:
  - "make -C docker build-travis"

script:
  - "./run-heimdallr-docker-noninteractive"

micha14:09:34

that lifts me out of weird travis DSL land

micha14:09:42

and into a place where i can actually program

micha14:09:05

form there it's pretty smooth sailing

dominicm14:09:10

Hasn't rkt taken off yet?

micha14:09:17

what is rkt?

dominicm14:09:26

That was an accidental pun, but I like it

dominicm14:09:36

CoreOS' version of docker which isn't insecure as hell.

dominicm14:09:58

Doesn't have to run as root!

dominicm14:09:51

Compatible with dockerfiles as well. CoreOS created an independent standard (AppC) that others can use to build images, and anything that understands AppC can run them.

alandipert14:09:46

an alternative to what micha proposed, which is to basically write the same thing in clj and AOT just it

agile_geek14:09:28

@dominicm in Java you would usually control the source and target jvm versions in maven (or ant) so you don't get differences across development machines but the final build would usually be on a consistent env like a CI server (server farm) - https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html

micha14:09:43

@alandipert we should make a main task in boot built_in perhaps

alandipert14:09:08

@micha it would be worht adding if it sets up the boot runtime

alandipert14:09:15

then we can uberboot

micha14:09:25

i mean just to make the shim you have there

micha14:09:36

if you just want an uberjar

micha14:09:40

and don't want boot

micha14:09:59

maybe an option to the jar task?

micha14:09:33

or maybe as an option to the aot task

micha14:09:28

boot aot --shim app.main-class:app.main/-main jar --main app.main-class ...

micha14:09:31

boot jar --entrypoint app.main/-main

alandipert14:09:35

yeah, i was gonna say jar

micha14:09:48

then the actual name of the jar's main class can be gensym

micha14:09:02

you can always get it from the manifest if you care

micha14:09:55

i think that would even work with an uberboot situation

micha14:09:07

you just specify the --entrypoint as the uberboot class

micha14:09:36

eh nm that is confus

dominicm14:09:02

Would a shim-main task make sense? Which adds a shim into the fileset?

alandipert14:09:15

yeah, that's what we're contemplating

alandipert14:09:26

just, as a flag to an existing task

dominicm14:09:55

@alandipert Your boot-uberjar example, puts the source code in :resource-paths, I can't seem to get the old version of yours to bring in other .clj files, if I use :source-paths, that seems like a mistake?

alandipert15:09:19

source-paths don't make it to jars

alandipert15:09:42

is that what you're seeing?

dominicm15:09:56

@alandipert Yeah.

alandipert15:09:00

it works if you AOT them because the resulting .class files do

dominicm15:09:08

Yeah, that makes sense.

dominicm15:09:23

Why don't source-paths go into jars? Does that mean clj files aren't source-paths?

alandipert15:09:30

so yeah, if you're not aot-ing, should put them in resource-paths

dominicm15:09:37

I'm full of questions today 😁

alandipert15:09:54

well a 'source' in boot lingo is a file without an 'output' role, ie it is destined to be consumed/transformed by a task

alexyakushev16:09:45

RE: AOT. Clojure libraries are not meant to be AOT-compiled, but final applications can be AOT-compiled. I AOT all of my apps in production.

alexyakushev16:09:36

It causes problems here and there, but mostly with things that are sloppy and dangerously written anyway.

micha16:09:07

@alexyakushev what is the benefit of AOT in your applications? are you making desktop applications?

alexyakushev16:09:28

Mostly for improved startup time

alexyakushev16:09:36

No, plain old backend services

micha16:09:20

i'm not aware of any runtime performance improvement you can get from AOT

micha16:09:25

other than startup

alexyakushev16:09:56

After everything is compiled by the runtime compiler, no, there shouldn't be any

micha16:09:24

perhaps if you pipe it thought the whole program optimizer...

micha16:09:30

i forget what it's called

alexyakushev16:09:20

You mean proguard?

anmonteiro16:09:11

I’m having an issue with boot-cljs-repl

anmonteiro16:09:25

let’s say I set up a cljs-repl, call start-repl

anmonteiro16:09:42

then (require ‘my-project.ns) (in-ns ‘my-project.ns)

anmonteiro16:09:00

however there don’t seem to be any definitions there?!

anmonteiro16:09:40

say I have a (def foo 42) in that namespace, when evaluating foo at the CLJS REPL I get

#object[TypeError TypeError: Cannot read property ‘foo' of undefined]

anmonteiro17:09:35

hrm, solved it by adding an explicit require in my main.cljs.edn

anmonteiro17:09:30

@martinklepsch reproduced the sift thingy again

anmonteiro17:09:44

without watch it seems to work

martinklepsch17:09:58

don't delete the cache now 😛

martinklepsch17:09:15

have you tried the two placements (before/after) watch task?

anmonteiro17:09:36

yeah, this happened with sift before the watch task

martinklepsch17:09:11

and does it happen with after as well? Any chance you can create a repro?

anmonteiro17:09:52

@martinklepsch hrm, I’ll try to create a repro, but can’t do it today though

anmonteiro17:09:28

and yeah, it happens with the watch task after too, that’s how I reproed the first time

pseud18:09:37

Anyone sitting on a good cljs project in using boot which builds an uberjar (ideally which is pushed to clojars)

martinklepsch18:09:17

usually you don't push uberjars to clojars, what are you trying to achieve generally?

pseud18:09:55

I admittedly have very little knowledge of what I’m doing (well, aside from writing code, hopefully)

pseud18:09:47

@martinklepsch but what I’m trying to do, in a nutshell, is to convert one project of mine from lein to boot for which I have a (über?)jar up on clojars (via “lein deploy”…)

pseud18:09:26

So I’m basically trying to make everything build, create a (über?)jar, deploy the thing and hopefully stop using lein for that project.

martinklepsch18:09:57

@pseud is it a library others consume via maven?

pseud18:09:18

My understanding is that lein uses maven repos, so yes

dominicm19:09:30

@alexyakushev That's good to know. I might try AOT'ing everything, especially if I can figure out a way to keep out the test deps from the AOT

pseud19:09:31

and a follow-up question, why is it I can’t seem to find any info on compiling cljc files as part of a boot-based cljs project ?

dominicm19:09:46

@pseud They don't need compiling really 🙂. They're just treated as normal clojure files.

martinklepsch19:09:58

@pseud so an uberjar usually refers to a jar that includes all dependencies — is that what you want?

pseud19:09:30

well, my boot project right now complains they’re not on the classpath during compilation. Of course, I freely admit to knowing very little. But it seems to me that it’s helpful to have some sort of quick-start project examples because if there’s anything I’ve learned from the many languages I’ve played with, it is that oftentimes those who write code are oblivious to packaging etc and thus there’s less code shared than there could be 😞

dominicm19:09:35

It's hard to know what leiningen is actually doing on your behalf sometimes, did you go out of your way to make it an uberjar that gets pushed?

pseud19:09:14

@dominicm nope - I really admit I have no clue. “lein deploy” pushed to clojars, I could use my lib in another project, I was a happy camper

martinklepsch19:09:55

any chance you can paste the project.clj?

dominicm19:09:17

@pseud I don't think that was an uberjar.

pseud19:09:18

project.clj ? You want to see the old lein project ?

martinklepsch19:09:18

yes, seeing that we can probably infer what you're trying to reproduce

pseud19:09:03

OK - keep in mind I’m forced to go through the motions here faster than I’d like (need to share such that some colleagues can start playing with it) - that’s why code might be rushed and especially why the project files and such might be messy. That said: https://github.com/readux/readux And this is what I’m using with boot right now (~1hr into it): https://gist.github.com/jwdevantier/093af02cc1d65994c34d4c45ba33b7a3

dominicm19:09:22

@alandipert https://github.com/adzerk-oss/boot-cljs-example/blob/master/build.boot should this be using :source-paths for the cljs? As they're an input with an output?

dominicm19:09:34

@pseud: Try:

:source-paths #{"src/cljs"}
:resource-paths #{"src/cljc"}

martinklepsch19:09:49

@pseud so you don't need uber

martinklepsch19:09:04

and to push the jar to clojars try (push :repo "clojars")

martinklepsch19:09:30

also aot and target are not necessary

pseud19:09:32

@martinklepsch but if I leave off target I don’t really know where the output file goes ?

pseud19:09:10

(And I’m assuming then the aot(ahead-of-time) only applies to actually compiling clojure code proper to what.. java bytecode to avoid being interpreted at first?)

dominicm19:09:10

@pseud So, if you're pushing it, it goes straight to clojars 🙂

pseud19:09:51

@dominicm well with lein I had the ability to do “lein install” a few times over to use a local test project just to see that I hadn’t royally screwed everything up 😉 I’d like that option still, if possible

pseud19:09:04

Actually, re-consulting “boot install -h” answered that part.

martinklepsch19:09:10

try this

(deftask build
  "Build a jar file"
  []
  (comp (pom) (jar) (install)))

martinklepsch19:09:26

and once you want to push to clojars just do

boot build push --repo clojars

pseud19:09:55

Yup, just now realising that 🙂

alandipert19:09:29

@dominicm re: source/resource in cljs example, i think yes. the distinction usually boils down to that of application vs. library

alandipert19:09:50

@dominicm applications don't care if cljs ends up in artifact, but that's the purpose of libraries and they must include them in jar

dominicm19:09:52

@alandipert Oh I see. I hadn't considered that.

dominicm19:09:27

@alandipert I guess that means that @pseud should do: :resource-paths #{"src/cljs" "src/cljc"} then?

pseud20:09:46

@dominicm seems like it, if I stuff everything in :source-paths the files are simply not included at all. However, if I use :resource-paths then the files are included in the jar.

pseud20:09:00

(got that from opening up the jar in a zip archiver program)

pseud20:09:29

(Oh, and I should be said, I started digging into that when I got errors from using my newly minted jar in a local project - w/o using :resource-paths I would get errors pertaining to missing files)

dominicm20:09:31

@pseud: afk now but there Is a link to the boot wiki with this information

dominicm20:09:19

Yeah. It's a little complicated. I might blog on it based on what I have learned 😃

pseud20:09:27

@dominicm OK - thanks for your help today - really appreciated

dominicm20:09:39

@pseud: no problem. 😃

pseud21:09:11

Wondering if anyone uses checkout dependencies. I’ve uploaded a small-ish example and annotated in the readme how I’ve put the tasks together, what stumps me is that whether using these, or the verbatim (well, sans artifact-id & version numbers) instructions of “boot checkout -h” I get an error like "ERROR: No such namespace: readux-0.1.2-SNAPSHOT.readux.core”. Anyone used checkout dependencies successfully ? Anyone got any public projects to share ?

kenny21:09:07

@pseud You just add :checkouts to your boot environment with the value being a vector of the dependencies you want checked out.

kenny21:09:36

It might look like this:

:checkouts '[[foo/bar "0.1.0"]]

kenny21:09:11

Then in the checkout project you can do something like this:

$ boot watch pom jar install

martinklepsch21:09:07

@pseud don't forget the ' in font of that vector

kenny21:09:12

If you want to reload a file in the REPL from foo/bar you just (require 'foo.bar.core :reload)

pseud21:09:34

assuming that’s correct - how’d you figure out that adding a “:checkouts” key to the env of the dependent project would do the trick ? I mean, I looked at “boot checkout -h"

martinklepsch21:09:58

> Checkout dependencies task. DEPRECATED

martinklepsch22:09:16

That task is deprecated but probably that could be stated more prominently

martinklepsch22:09:40

it has moved to the global env which is what @kenny described

kenny22:09:56

I don't think there is a wiki page for it yet

kenny22:09:03

There should be though 🙂

pseud22:09:25

Ah.. Snap. yea.. Well, in my defence (and indeed the output from “boot -h checkout” 😛 ), I’m tired as hell. It’s probably clear enough.

pseud22:09:59

And it works like a beaut. Happy times ! 🙂 Thanks oh so very much

martinklepsch22:09:13

no worries, after a good night of sleep it'll be clear as day 🙂

pseud22:09:24

that’s what I’ll be telling myself 😛