I use a formatting tool and occasionally a string-pluging in intellij. lemme check

The plugin is called string manipulation and allows you to sort a subselection. This works for me because i can order arbitrary selections such as :dependencies in project.clj

oh right that sounds neat! I’ll try it out

We use https://github.com/gfredericks/how-to-ns with :sort-clauses? true as the linter btw

oooh thanks 🙇

If you have IDEA 2019.2, there's a pinned post explaining the issue.

ah, thanks. I'll keep that in mind if it breaks again

There’s only one Aliases tree in the toolwindow, and those aliases apply to all projects. That’s because there’s no way to pass aliases transitively to sub-projects in deps. However that aliases tree isn’t used at all for run configs like REPLs, it’s only used when syncing the project to IntelliJ.

To add an alias when running a REPL, in your REPL run config choose “Run with Deps”, choose module B, and you should be able to just enter the aliases in the alias box there.

I see multiple Aliases folders - one under each sub project. The bigger issue was that every time I changed the deps in library B, Cursive won't refresh its deps.

Is there a way to refresh the deps for library B?

This is actually quite a big annoyance. We have several cases like this and none of them will refresh their deps without refreshing a parent lib first.

In library B, all the deps in the :test alias are never refreshed and therefore all marked as "cannot be resolved"

This has another consequence - all symbols that have been marked as Resolve as... change their indentation back to the default. This causes code to get reformatted with no way to fix it.

So you want to be able to refresh the deps for B without refreshing A?

Definitely

Why is it a problem to refresh A?

Further, refreshing A does not cause the changes in B's :test alias to get updated.

Because I am working in project B independent of A.

Sure, I understand it’s slightly counterintuitive, but does it actually cause a problem if you refresh A in order to refresh B?

Yes. That does not work when changing deps in B's aliases.

Yeah, the alias thing is annoying.

ok, I’ll look at that - thanks for the report. Unfortunately the Deps support is based on an inflexible IntelliJ API. I want to migrate it off due to all the recent breakage and problems like this, but it’s a big job.

Right. It's quite an issue for our setup. It's possible that removing all project-A type projects, then adding all project-B type projects, then adding project-A type back in again would work.

There's no way to even load a test file stored in project B.

You will always get "Cannot load metrics_stream_test.clj file into the active REPL. It is not in scope for the module used to start the REPL."

Is that a REPL started with module B as the context module?

Deps doesn’t make this any easier unfortunately, since aliases are not transitive there either.

Yes but if you changed the paths in the :test alias, it never updates.

Oh I see, so the problem is also that B’s :extra-paths are never added?

Just tested that. I need to refresh project A to get it to update -- no auto import.

So the project is just with the :extra-deps.

Oh, I see - changes in B’s project are not auto-imported. If changes in B’s deps.edn triggered an auto-import of A, would that be ok?

I suppose that would work.

But it needs to apply for aliases as well.

Yes, I think that’s a separate issue.

We can do what you mentioned earlier by specifying the aliases explicitly in the "Run with Deps" text box. That approach will let you load things in the REPL but not resolve symbols from the aliases specified. This is annoying and leads to bad formatting of code using the unresolved symbols.

Yes, definitely both cases need to work.

Let me just capture all this in an issue and I’ll get you to look it over.

Haha ok. Not sure if IntelliJ APIs are a blocker here but being able to move a Module's "sub-module" to a top level Module would fix this too.

Yeah, I can’t do that, unfortunately.

I really hate that thing.

I should have just duplicated the lein integration, which works great now.

Hmm, ok. Another possible workaround would be to disable the local/root auto module import thing for certain projects and let the user explicitly add them as a module.

Does this capture it all? https://github.com/cursive-ide/cursive/issues/2214

4. This actually works with the caveat that your deps in the :test alias may not actually be on the classpath. Not sure how the suggested solution would really solve the problem though. You'd need to know which aliases in project B to update.

Yes, you’d have to do that selecting the Aliases in the A project, which means you need to know how B was pulled into the project.

Ohhh. B's aliases show up in A?

Yes.

At least, I think so.

Ah, I had no idea haha. +1 for changing that to be more intuitive 🙂

It’s actually worse than that, if you also have another top-level project C which also pulls in B, then the aliases will be different there.

The way that lein works is that there’s one single top-level Profiles tree, which applies globally to all projects.

Maybe that is the simplest solution here. It’s what I thought I had implemented, but I didn’t realise that the aliases are currently per-project.

Hmm. So that makes sense for the resolving of symbols in the editor. It isn't great for starting a REPL. The Run with Deps should let you select the aliases per project though.

Yes, that is different and configured as you describe for lein.

That's much clearer than the way it is now, IMO.

Ok, I’ll try to fix that. That would hopefully fix a lot of the confusion.

If you take a step back, really aliases should be per-project. That's the mindset you have when working with deps.edn so that's the mindset people would have when working with Cursive. Whether that actually fits into IntelliJ's model is another story, it sounds like.

Do you mean per-deps.edn, or per-IntelliJ project (i.e. per-all-your-deps.edn)?

per-deps.edn. IntelliJ projects are just a way of viewing many individual deps.edn projects.

Right. However literally no-one has ever complained about the profiles support in lein, and it’s how the Maven support in IntelliJ works too.

I think you’d have to get pretty crazy with inconsistent meanings for the same aliases for a global list (for project sync purposes) to become a problem.

Thinking about it, it would only be a problem if you have an alias that pulls in a dep or adds a source root for one project, which also pulls in things in a different project that you don’t want. For project sync purposes you mostly want a superset of everything anyway, so it seems unlikely to cause a problem.

Sure, that's fair. The reason it feels weird to me is it is conflating IntelliJ's definition of projects with deps.edn's definition of projects.

Right, but the same is true of lein and Maven, and it’s not been a point of confusion there (at least, definitely not for lein)

I'm curious if there's other reasons for that. deps.edn has certainly changed my mental model for this stuff.

Anyway, having a superset for resolving symbols would work. I can't think of a reason why you wouldn't want that. You would then (always?) want to select the individual project-level aliases to start your REPL with.

Yes, definitely, no plans to change that part.

Maybe some checkboxes in the run configuration box so I can remember what aliases are available in that project? :)

So, I’ll fix the global alias bit. That was my intention anyway, and I didn’t realise it wasn’t working like that. If there do turn out to be problems with that, I can perhaps allow customisation of the global list at a project level if required.

Hehe, sure, or autocomplete perhaps.

Thank you so much! This will be a huge fix for us.

Ok, this sucks. I cannot make that change, nor can I change this in any non-confusing way.

I’m going to migrate the deps support off that API. It will probably take ~2 weeks, but it’s going to be my main focus until I get it done.

Then I’ll be able to do whatever changes I need to, and you’ll have new and exciting bugs to find 🙂

Sorry for the wait.

Haha it’s ok. Happy to help make Cursive better!

Cool, I’ll let you know when I have a dev build worth testing.

👍:skin-tone-2:

Not sure. Was looking for plugin settings but no luck. Do I miss anything? "Paredit" toggle appears only in my quick actions but it doesn't affect my issue.

Ok, it's controlled by Edit -> Toggle Structural Editing Style.

And, in case I want to keep it on, then Raise does the unwrapping. Thanks, rubber duck in its glory))

👍

Two cents, it's common to have Unwrap action in IntelliJ, usually, bind to Ctrl + Shift + Delete. Could be a secondary key mapping for Raise. Awesome plugin, overall!