This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-04
Channels
- # aleph (24)
- # beginners (60)
- # cider (20)
- # clara (4)
- # cljs-dev (13)
- # cljsrn (4)
- # clojure (66)
- # clojure-italy (32)
- # clojure-nl (4)
- # clojure-serbia (1)
- # clojure-uk (207)
- # clojurescript (115)
- # cursive (3)
- # datomic (36)
- # defnpodcast (1)
- # duct (15)
- # fulcro (14)
- # graphql (8)
- # lein-figwheel (1)
- # leiningen (4)
- # off-topic (140)
- # pedestal (40)
- # portkey (3)
- # reagent (40)
- # remote-jobs (1)
- # ring (11)
- # shadow-cljs (31)
- # spacemacs (6)
- # sql (65)
- # tools-deps (67)
- # yada (1)
I’m looking into the nix package manager right now and wonder if classpath caching was inspired by this maybe?
@borkdude as someone without fear of parens guix might also be of interest to you. It’s basically nix written in scheme.
what are the rules for downloading snapshots? i have two extra :mvn/repos
defined (Datomic’s, and our own S3 one), and for some reason, tools.deps
is failing on figwheel.main
’s dep because it’s not attempting it on the one repo that has it - http://clojars.org.
gosh, nevermind. i had a non-standard space after the dep name, which caused it to be included in the dep name 🙈
I'm having an issue I don't really understand, I'm trying to depend on jnr-posix, with lein all is happy, and with clojure tools the same snippet doesn't work.
com.github.jnr/jnr-posix {:mvn/version "3.0.42"}
is the version.
user=> (import
#_=> (jnr.posix POSIXFactory POSIXHandler))
jnr.posix.POSIXHandler
user=> (POSIXFactory/getNativePOSIX)
#object[jnr.posix.LinuxPOSIX 0x6dd5e5ec "jnr.posix.LinuxPOSIX@6dd5e5ec"]
Is the snippet that does work in lein, but not in clojure cli tools.
I even tried doing lein deps :tree
and using those dependencies in deps.edn:
{com.github.jnr/jnr-posix {:mvn/version "3.0.42"}
com.github.jnr/jnr-constants {:mvn/version "0.9.9"}
com.github.jnr/jnr-ffi {:mvn/version "2.1.7"}
com.github.jnr/jffi {:mvn/version "1.2.16"}
com.github.jnr/jnr-x86asm {:mvn/version "1.0.2"}
org.ow2.asm/asm-analysis {:mvn/version "5.0.3"}
org.ow2.asm/asm-commons {:mvn/version "5.0.3"}
org.ow2.asm/asm-tree {:mvn/version "5.0.3"}
org.ow2.asm/asm-util {:mvn/version "5.0.3"}
org.ow2.asm/asm {:mvn/version "5.0.3"}}
But that hasn't resolved the issue either.Looks like in the deps.edn version, (
doesn't resolve.
you could pull the other classifiers in as local jars
{:deps {madeup/dep {:local/root "path/to/the.jar"}}}
@alexmiller this is in pack, I'd like to keep the repo small (no jars in the repo). But I've done that into my maven repo for now, only I need to run the tests, right?
Trying to write some tests for pack, which involves changing the jvm directory in order to have :local/root "../blah"
work correctly.
I don’t understand what you’re saying, sorry
@alexmiller I'm changing the cwd of the process so that relative paths work in deps.edn files.
https://www.engineyard.com/blog/bats-test-command-line-tools maybe this would have been less effort...
I'd like to make a script to run tests and launch that script with clj
. Something like clj -A:test -m test-runner
. In order to run tests, you need to know which namespaces you want to test. To determine the namespaces to test you need to find all namespaces given some file system paths. I'd like to be able to figure out the file system paths from the super set of :paths
and :extra-paths
in your deps config files given the aliases you passed to the clj
command. I can't see a way to get the aliases you used to launch the clj
command. Any ideas?
@kenny Have you looked at Cognitect Labs' test-runner
project?
Oh cool! Seems like that project takes a different approach by defaulting to test
directory otherwise you need to explicitly specify the directory for your tests. I suppose that'd work.
See https://github.com/seancorfield/dot-clojure for an example of using test-runner
where the tests could be set by an alias (I specifically run tests with clj -A:test:runner
-- where :test
can vary by project)
Here's an example of that test-runner
used with multi-version testing https://github.com/clojure/java.jdbc/blob/master/deps.edn
> I can't see a way to get the aliases you used to launch the clj
command. Any ideas?
I'm not sure why you'd need/want this?
You can't do anything with those aliases...
There are lots of things I can do with the aliases. I can use them to determine information about the deps.edn file. I can launch sub-processes with the same classpath as the parent process.
So this isn't a real world need, just a "what if"?
Can you elaborate? What, specifically, are you trying to do where knowing the actual aliases used would be a solution?
A simple example would be to get a set of all :paths
and :extra-paths
used to launch the JVM via clj
.
You can already get the classpath in any JVM program... and then you can walk that to see which are directories and which are files...
The set of all directories on the classpath may be a super set of :paths
, :extra-paths
, and other directories with no way to differentiate the three.
And you need to tell them apart because... why?
Sorry, I'm still not understanding the actual problem you're trying to solve here. I'll just give up and go away.
Sorry, I should have started with the most precise, minimal problem.
I'd like to get a list of files within the :paths
and :extra-paths
for the clj
launched JVM within the JVM.
Yes, you keep saying that, but I still don't understand what problem you are trying to solve.
It could be anything - this will be used for general operations over your project files. For example, I may want to run a formatter over all my project files. As done in the test-runner you sent, I could require the user to explicitly pass the directory and default to something like ["src" "test"]
. It seems preferable, however, to default to the current set of files within :paths
and :extra-paths
because these are the files you are currently working with.
Why not use the current working directory where the <insert general tooling> was invoked, and walk the classpath for paths that include that directory as a prefix? Then you have something that is general and could be invoked via clj
, lein
, or boot
.
(with an option to specify paths as -main
arguments)
But why require the user to specify a prefix when they already included the directories they want via aliases?
Re-read what I suggested.
The user would not have to specify a prefix.
Then the tooling you produce really is general rather than being hardwired to some implementation artifact of how clj
happens to work today.
I don't believe that is general though. You can specify a path via an alias that is not in the parent path.
If :paths
or :extra-paths
end up pointing to directories outside the project where you invoked clj
(and your imaginary tooling), I think most people would be surprised that it performed operations on those files, rather than what is local inside the current project folder...?
Perhaps. But they also explicitly included that as a :path
instead of a local dependency so they probably have a reason for doing.
this should be considered highly unusual and possibly even a bug
I think you're trying to solve a non-problem and making your tooling set up more complicated (and more brittle) than it needs to be.
Solve the simple, obvious use case first -- using just the current working directory and the classpath, which is the general tool-agnostic case -- and then see if any of your users really do things differently.
(I've learned this the hard way with boot-tools-deps
-- with hindsight, I would have done that very differently)
Would you prefer the test-runner project default to directories on the classpath that are prefixed with your current directory or simply the "test"
directory?
For a test runner, it makes sense to provide an external, tool-agnostic way to specify where to find tests -- since you already know the source code is going to be on the classpath (as well as the test code).
For example, in simple Clojure projects, src
and test
are the two top-level folders. In mixed clj/cljs projects, you often have src/clj
, src/cljc
, src/cljs
(and similarly for test
) so specifying just what should be run on the JVM is already more complex. And in Maven-style projects, tests are under src/test
-- where source code is under src/main
(and those tend to have <language>
as the next level and then the actual code tree).