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.

cool

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 🙈

that's horribly awesome.

maybe write a patch for Clojure to treat that like the other whitespace 😛

How will I drive my co-workers crazy then?

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"]

{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"}}

Looks like in the deps.edn version, ( "jni/x86_64-Linux/libjffi-1.2.so") doesn't resolve.

OH, I see. It's because jffi has a native classifier.

TDEPS-50 and 12. No fun being here 😛

Is there any known workarounds?

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.

So that I can write tests for pack

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?

https://github.com/cognitect-labs/test-runner

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.

I still think it would be useful to introspect the clj props used to launch the JVM.

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

https://github.com/clojure/java.jdbc/blob/master/run-tests.sh#L47

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

Makes sense.

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"?

It is real world because that's the exact problem I'm running into right now 🙂

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

Doesn't work with local deps 😉

:local/root

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?

Differentiate files in your current project from dependencies.

I simply want a list of files in :paths and :extra-paths.

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.

Oh I see.

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.

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.

That's fair 🙂

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

Makes sense. Thanks for the direction.