Fork me on GitHub
#leiningen
<
2018-01-10
>
gfredericks16:01:53

I'm showing lein run and friends not loading src/user.clj; is there something obvious I'm missing?

gfredericks16:01:59

lein classpath definitely shows the src directory

noisesmith18:01:03

is there another user.clj on classpath before it maybe?

gfredericks19:01:28

I meant to investigate that...clj only picks up the first?

gfredericks19:01:52

yeah, there was another one

noisesmith19:01:58

it would be interesting to make an extension that loads all user.clj on classpath root and not just the first one

gfredericks19:01:04

you could drop that functionality in your user.clj

noisesmith19:01:17

haha as long as its first

gfredericks19:01:44

yeah; less of a joke, you could have the convention of loading all user.*.clj files, and put the code for that in your user.clj

noisesmith19:01:23

abbot and costello, “who’s on classpath”

xiongtx19:01:26

For leiningen, what’s the use case for :scope "provided" vs. a dev-profile dependency? I’ve seen the former in a few places, e.g. tools.reader: https://github.com/clojure/tools.reader/blob/tools.reader-1.1.1/project.clj#L11

noisesmith19:01:45

the provided scope is for things that you want the user to provide and never want to provide transitively from your own code - this can be useful if the dep is known to come with a framework the user is using for example

xiongtx19:01:19

Seems that’s some thing that can also be put into the :dev profile, no?

xiongtx19:01:03

If tools.reader specified a version of cljs in the :dev profile, then that’ll be the version used when developing it, but won’t be included in the artifact--or am I wrong about that?

noisesmith19:01:09

if it was in the dev profile it wouldnt’ be available while building a jar for example - it might need to use cljs to package

noisesmith19:01:01

another example being running tests

xiongtx19:01:16

Pretty sure tests make use of :dev profile…

noisesmith19:01:09

oh you’re right, sorry

noisesmith19:01:24

>The :provided profile is used to specify dependencies that should be available during jar creation, but not propagated to other code that depends on your project. These are dependencies that the project assumes will be provided by whatever environment the jar is used in, but are needed during the development of the project. This is often used for frameworks like Hadoop that provide their own copies of certain libraries.

noisesmith19:01:43

it’s specifically about things used while creating a jar that shouldn’t go in the jar https://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md

xiongtx20:01:49

Wouldn’t we assume the user’s providing their own clj?

noisesmith20:01:06

leiningen special cases clojure deps iirc - since it’s the one dep that a project must always have in scope to build, but almost never something that should be transitively provided, but I’d have to double check that

danielcompton20:01:32

I think you're technically correct that you could do everything or most things with a :dev profile instead of "provided", but it communicates the intent much better using "provided"

danielcompton20:01:58

One is saying "This is for me to develop the library with, but is not needed for consuming this library", the other is saying "You need to provide a version of this, as I can't presume what you will have"

xiongtx21:01:24

Yes, thanks for clearly differentiating b/t the two intents. That makes it clear

noisesmith19:01:12

they want you to explicitly pick a clojurescript, they don’t want to implicitly give you a cljs version