@kenny the issue is because of ecdsa I believe.

It's a bit frustrating to have to wait so long for Windows support. https://dev.clojure.org/jira/browse/TDEPS-67 has been around for a while... Please add your vote! (not sure if it'll make a difference but it can't hurt). Thanks

We're developing a situation where a few aliases have been split up in the name of DRY. This means that to start the project in "dev mode" requires a difficult number of aliases. Has anyone tried tackling this yet? I'm currently thinking of writing something that merges together aliases so you can create a "super-alias" that's easier to maintain.

This is really just a workaround for the lack of ability for aliases to depend on one another.

@dominicm Yeah, we're running into that a bit as we convert our Boot-powered monorepo to clj/`deps.edn`...

@seancorfield have you had any particular ideas on how to tackle it? I'm quite happy to open source my solution. It will likely be a key piece in edge.

have you considered just repeating yourself? :)

@alexmiller In some cases, yep! For a single dependency it's usually not so bad. When it's 2 or 3 aliases with 2 or 3 changes, the maintenance burden of bumping in multiple places is failing quite often. I'll admit that I'm trying to add in more "easy" onto this design than usual, as I can't impose pull request standards onto all projects.

We've had to repeat a chunk of our testing context in two separate aliases, which is a bit annoying. The alternative is a longer string of aliases. Right now we have a dummy project containing a deps.edn with mostly aliases. That has a :default aliases which has all our :override-deps where we "pin" versions of libraries. Then we have a deps.edn in each project that specifies the deps for that project (mostly as some/lib {} since the actual version comes from the :default alias) and references to other subprojects as worldsingles/something {:local/root "../something"}. This works pretty well for working within any given subproject and then we'll likely have a couple of shell scripts for running tests across the whole suite of projects.

Doing this has actually highlighted some problematic cross-project dependencies that Boot sort of hid for us, so that's been nice. And of course being able to use a much more lightweight process is always nice 🙂

heh, I actually just caught myself this second failing to update one of two places. I only caught it because I realized that a :main-opts looked out of place in the alias I had updated.

One thing I do find is that I'd desperately love to be able to parameterize deps.edn sometimes. For example, we can have an alias that starts an nREPL server to work with a project in an editor, but we can't affect which port it starts on -- that has to be hardcoded in the alias. So I'm thinking we may end up with one or more aliases that bring in (and run) certain small Clojure scripts that exist purely to support dev/test work. That way we could do clj -A:some:stuff:here <port-number> and run a -main in a dev namespace that starts nREPL on that port.

I'd be interested to hear more about how Cognitect folks deal with this in large projects. hint, hint @alexmiller 🙂

don’t make large projects?

scowl

Is 63K lines of production Clojure and 20K lines of tests "large" tho'?

deps.edn being “just data” (and not having parameters, references, etc) has vast benefits for “simple” and is not something I will give up easily

at some point of complexity, you are really doing programming here

Oh, true. I totally get the benefits. I just haven't (yet) found the ideal balance yet, with the new tooling.

you can use clj to run programs - so pushing it into a script (which can take args) is one path

@seancorfield I'm in favor of a main for the nREPL situation.

you can also wrap clj in another program (probably a shell script)

but could also be, say, make

make has the nice capability to define dependencies on smaller pieces which I think often is useful in build situations where you are making dependent subtasks

ditto ant

Being able to do something like this to run all subprojects tests is convenient enough:

for d in * ; do (cd $d; CLJ_CONFIG=../versions clj -A:defaults:test:runner); done

We're trying hard to get away from Ant. All that XML shudder

I don’t think running a standard “program” per project is any different though

Yeah, hence why I'm coming around to having a "dev" project with short Clojure scripts with -main entry points. And, to be honest, that's not hugely different from having tasks in a build.boot file which are all just functions.

@seancorfield would the dev project be a dependency of all projects?

Only under an alias for dev/test tooling -- it wouldn't be a regular dependency.

sorry, yeah.

@seancorfield once add-lib is stable, it might be a good idea to dynamically fetch dependencies based on the task(s) being run. e.g. nrepl will grab cider/tools.nrepl on demand. That would probably reduce the number of aliases way down. Basically making most of the project static (deps.edn) but providing a dynamism for the non-simple stuff.

I dream of a world where tooling bootstraps itself on top of prepl instead of needing server-side dependencies 🙂

(I love unravel for that reason)

socket repl already does that, but I agree 🙂. But I think the same applies (for me) for loading in cljs to do a one-time build.

Well, specifically the tooling. I'd like to see a version of CIDER that could bootstrap itself over a socket REPL or prepl. So you didn't need all the CIDER deps on the project side of the equation. Same with ProtoREPL for Atom.

What I like about unravel is that I can spin up a bare Socket REPL (e.g., on a production JAR, via JVM options) and then connect via unravel and when I (require 'compliment.core) it sends it over the wire from the REPL client so I don't need it in my project. Then I have a nice interactive REPL with history, documentation hinting, completion...

Your project then becomes tooling neutral. You don't need any dependencies in it to support tooling. And then you can use any tooling with it. I know CIDER can inject itself into a newly-started REPL process, but that's a heavyweight server containing all of those dependencies. I basically want CIDER-like functionality over a bare Socket REPL started from a JAR that doesn't have those dependencies 🙂

I just discovered I can use find-deps as a filter! Nice. This means I can do !aE in vim, followed by my find-deps command to auto-update the buffer I'm working on. Cool!

@alexmiller have you had any thoughts about comments being obliterated by -Sresolve-tags?

I should open a jira if there isn't one

reader doesn’t preserve comments

I’m not planning on doing any more work on resolve-tags. most likely will actually extract it all out into a separate project and remove it entirely

as an external program you could invoke it from clj if needed

If it's an external program that shifts expectations I think, cool. I would be more inclined to reimplement it with rewrite-clj so I could preserve comments/formatting.

I've been thinking about whether a wrapper over rewrite-clj that implements IAssoc is feasible.

Well feel free to rewrite it and make it do whatever :)

@seancorfield have you seen https://github.com/Unrepl/unrepl? It does pretty much that self-bootstrapping dance.

@arrdem yes I use that with socket server REPLs a lot.

It can bootstrap compliment into a running REPL to give you auto-completion, which I like.

I guess bootstrap here just means "send the necessary text across the socket to define functions/etc. to create the necessary code on the server?"

Yeah. In this case, "send the Compliment library across the socket..."