Fork me on GitHub
#tools-deps
<
2019-06-21
>
stathissideris10:06:19

does :jvm-opts work only within aliases or at the top-level too?

kszabo10:06:34

only aliases, it’s a known issue

stathissideris10:06:47

ok, thanks! (glad to hear it’s a bug and not a feature)

misha17:06:46

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.)

misha17:06:34

no for both 1 and 2?

misha17:06:09

what is the preferred way to go about it? separate repo with specs?

misha17:06:57

do :aliases extra deps appear in client's class path?

misha17:06:45

if no, that makes extra repo option not that bad

hiredman17:06:53

I maybe have misunderstood 1

misha17:06:52

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

seancorfield17:06:54

:aliases are not transitive across dependencies, if that's what you're asking @misha?

hiredman17:06:40

so 1, the dep on clojure.spec is going to be there, clojure pulls it in

misha17:06:23

so: specs-repo + lib-repo + specs-repo-as-alias-extra-dep for tests is an ok solution

hiredman17:06:51

or just put your specs in a namespace and don't load that namespace except from tests

misha17:06:06

oh, right. then: can I not depend on clojure in my lib repo? )

seancorfield17:06:08

In separate repos, yes, I guess that could work -- but I don't know why anyone would bother?

seancorfield17:06:57

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.

misha17:06:08

trying to avoid any transitive deps you'll get by using my lib

seancorfield17:06:58

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.

misha17:06:01

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

hiredman17:06:07

spec comes with clojure these days, but is technically a separate artifact so you can use a newer version if you want

seancorfield17:06:12

You can't avoid clojure.spec.

seancorfield17:06:46

Clojure itself pulls in clojure.spec and core.specs. The client is always going to get those.

misha17:06:10

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.

seancorfield17:06:13

You can avoid test.check (by making it a :test-only :extra-deps).

seancorfield17:06:59

@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.

misha17:06:13

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?

seancorfield17:06:41

The Clojure dependency will be overridden by the client.

misha18:06:17

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.

seancorfield18:06:56

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.

misha18:06:28

You are right, clojure includes spec, I have to include clojure, so it boils down only to "make specs public or not". thanks, guys.

seancorfield18:06:59

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.

seancorfield18:06:54

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).

misha18:06:24

this is exactly how I am approaching it now. Docstrings – contract, validation – optional, in a separate ns

andy.fingerhut19:06:55

Fun fact. This works: clj -Sdeps "{:deps {org.clojure/clojure {:mvn/version \"1.0.0\"}}}"

andy.fingerhut19:06:13

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.

seancorfield19:06:47

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

seancorfield19:06:53

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=> 

andy.fingerhut19:06:49

I'll file a ticket for a 1.0.1 release 🙂

12