This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-10
Channels
- # adventofcode (3)
- # aws (2)
- # beginners (85)
- # boot (8)
- # boot-dev (4)
- # cider (36)
- # clara (3)
- # cljs-dev (87)
- # cljsrn (3)
- # clojure (87)
- # clojure-austin (12)
- # clojure-brasil (1)
- # clojure-dev (8)
- # clojure-dusseldorf (5)
- # clojure-estonia (5)
- # clojure-greece (4)
- # clojure-italy (3)
- # clojure-spec (17)
- # clojure-uk (55)
- # clojurescript (70)
- # core-logic (2)
- # cursive (6)
- # data-science (18)
- # datomic (13)
- # emacs (34)
- # fulcro (347)
- # graphql (12)
- # hoplon (6)
- # jobs (3)
- # jobs-discuss (43)
- # juxt (2)
- # keechma (31)
- # leiningen (29)
- # lumo (2)
- # midje (2)
- # off-topic (118)
- # om-next (4)
- # onyx (39)
- # pedestal (6)
- # re-frame (85)
- # reagent (21)
- # remote-jobs (3)
- # ring (5)
- # rum (2)
- # shadow-cljs (126)
- # spacemacs (1)
- # sql (6)
I'm showing lein run
and friends not loading src/user.clj
; is there something obvious I'm missing?
lein classpath
definitely shows the src
directory
is there another user.clj on classpath before it maybe?
I meant to investigate that...clj only picks up the first?
yeah, there was another one
it would be interesting to make an extension that loads all user.clj on classpath root and not just the first one
you could drop that functionality in your user.clj
haha as long as its first
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
abbot and costello, “who’s on classpath”
For , 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
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
If tools.reader
specified a version of 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?
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
another example being running tests
oh you’re right, sorry
>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.
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
R.e. , I’m not sure why is "provided"
, but isn’t: https://github.com/clojure/tools.reader/blob/tools.reader-1.1.1/project.clj#L10
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
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"
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"
also see maven docs https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope for differentiating between provided
and test
they want you to explicitly pick a clojurescript, they don’t want to implicitly give you a cljs version