This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-21
Channels
- # announcements (9)
- # beginners (222)
- # boot (11)
- # calva (40)
- # cider (1)
- # clj-kondo (10)
- # cljs-dev (1)
- # cljsrn (8)
- # clojars (4)
- # clojure (50)
- # clojure-dev (4)
- # clojure-ecuador (1)
- # clojure-europe (4)
- # clojure-italy (3)
- # clojure-madison (2)
- # clojure-nl (26)
- # clojure-spec (86)
- # clojure-uk (34)
- # clojurescript (11)
- # clr (1)
- # cursive (46)
- # datomic (19)
- # emacs (4)
- # events (1)
- # fulcro (22)
- # graalvm (4)
- # graphql (2)
- # jobs-discuss (40)
- # leiningen (10)
- # luminus (6)
- # nrepl (7)
- # off-topic (18)
- # onyx (6)
- # overtone (1)
- # pedestal (2)
- # planck (1)
- # re-frame (5)
- # reagent (3)
- # reitit (8)
- # rewrite-clj (2)
- # shadow-cljs (139)
- # sql (4)
- # tools-deps (42)
does :jvm-opts
work only within aliases or at the top-level too?
ok, thanks! (glad to hear it’s a bug and not a feature)
1) can I add a dependency to library so that it can be seen from library (e.g. when run as alias), but is invisible to client library? I assume deps in :aliases
behave like that. and if so:
2) is there a way to depend on an alias of such a library?
Trying to have specs in my lib on one hand (for lib internal tests, and for lib's clients if they need them),
and as a lib client to be able to exclude them from dependency (in case I use another spec version, etc.)
I want to have specs for my lib. And want you to be able to depend on my lib excluding those specs (and clojure.spec) both at the same time
:aliases
are not transitive across dependencies, if that's what you're asking @misha?
or just put your specs in a namespace and don't load that namespace except from tests
In separate repos, yes, I guess that could work -- but I don't know why anyone would bother?
If your specs are part of yours tests (only) just put them in the test
folder that would be added by your :test
alias. Done.
What transitive deps would those be? Clients of your lib need whatever your src
depends on. They don't need what your test
code depends on.
Sean, those specs might be useful for you as a client. But if you dont care, I dont want you to get clojure.spec through my lib
spec comes with clojure these days, but is technically a separate artifact so you can use a newer version if you want
You can't avoid clojure.spec
.
Clojure itself pulls in clojure.spec
and core.specs
. The client is always going to get those.
I need specs for tests only, but I know those might be useful for clients as well. so core does not depend on those for functionality.
You can avoid test.check
(by making it a :test
-only :extra-deps
).
@misha I think you're overthinking this. If you want clients to have access to your specs as an option, put them in src
. If you don't want clients to have access to them, put them in test
.
ok. do I have to depend on clojure itself to distribute a lib? if yes, is it better to depend on as old version as possible?
The Clojure dependency will be overridden by the client.
I am absolutely overthinking it, but on the other hand I had bad experience with different versions of direct and transitive deps before. trying to not mess things up for anyone.
Yeah, I hear that... If you have test-only dependencies, put them under an alias as :extra-deps
. If you have source dependencies, those are going to end up as transitive dependency for your clients.
You are right, clojure includes spec, I have to include clojure, so it boils down only to "make specs public or not". thanks, guys.
As an example, both clojure.java.jdbc
and next.jdbc
have all their specs in a dedicated namespace that clients can require if they wish but otherwise they are not activated.
For clojure.java.jdbc
, I primarily made them optional like that so it could continue to run on older Clojure versions (that didn't support Spec). For next.jdbc
, I added them after the fact as an option for folks who want better error messages (since next.jdbc
sort of follows Clojure core's principle of "do the right thing as fast as possible; potentially explode in arbitrary ways if asked to do the wrong thing" (i.e., NPE or ClassCast or whatever).
this is exactly how I am approaching it now. Docstrings – contract, validation – optional, in a separate ns
Fun fact. This works: clj -Sdeps "{:deps {org.clojure/clojure {:mvn/version \"1.0.0\"}}}"
And if you are wondering, I tried it because it is helpful in tracking down when some functions were added to Clojure that do not (yet) have :added metadata, but should soon.
I didn't try going back any further than 1.2.1 https://github.com/seancorfield/dot-clojure/blob/master/deps.edn#L4-L15 but that's good to know @andy.fingerhut
Interesting little glitch in 1.0.0:
(! 563)-> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.0.0"}}}'
Clojure 1.0.0-
user=> (clojure-version)
"1.0.0-"
user=> *clojure-version*
{:major 1, :minor 0, :incremental 0, :qualifier ""}
user=> ^D
Fri Jun 21 12:53:28
(sean)-(jobs:0)-(~/clojure)
(! 564)-> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.1.0"}}}'
Clojure 1.1.0
user=> (clojure-version)
"1.1.0"
user=> *clojure-version*
{:major 1, :minor 1, :incremental 0, :qualifier ""}
user=>