(this is a monorepo setup with one top-level dir per module, each module has a deps.edn file)

maybe the current working dir is the project root not the dir the deps.edn is in?

I have such a project and it is working alright

using IJ 2019.3 and Cursive latest eap

1.9.1-eap1-2019.3

ok, I’m on 2019.2.4 and not eap

I’ll try that

I don't know if the 2019.3 upgrade is necessary, Cursive EAP should be able to work with 2019.2.4

Colin had to change how deps projects work sometime during the 1.9.0 eaps, so you might need to re-import the project

yes but I thought that work was released

It was, in 1.9.0

I have been working with this project I mentioned during the 1.9.0eap builds, through 1.9.0 and the latest eap

and haven't had any problems

tried 2019.3 and eap, didn’t help

same error

weird. Have you tried reimporting?

yes. remove and readd, invalidate+restart, all that jazz

do you have a top-level deps.edn?

or just the subprojects?

tools-deps/cursive can’t handle that, so I merged everything shared into each deps edn.

hmm I have a top-level one

how do you do that?

referencing all sub-projects as its deps

oh, but how do subprojects reference each other?

../foo

ok, that’s what’s not working

perhaps adding a top-level deps edn could help?

how does your TL deps reference the children? :deps directly?

top:

{:deps {foo {:local/root "foo"}
        bar {:local/root "bar"}}}

{:deps {bar {:local/root "../bar"}}}

oops no keywords in dep names tho (fixed)

my deps.edn is generated so it’s gitignored. I wonder if that matters

not sure

seems weird that it would, I’m using “use command line tools-deps” setting, so I assumed cursive is just shelling out

I imported this project at the root and ticked the 'search for projects recursively' thing

everything works fine from a terminal

I'm afraid my knowledge only extends this far

ah I think I understand now

well, no, actually I don’t fully

but I think it has something to do with aliases not being applied transitively

I need an alias set in order for resolution to work because I use :default-deps

this top-level deps edn I made fails lower down with not being able to find the version of some transitive dependency

that version is only known if the alias is applied to that upstream deps edn too

I guess the command line tool does this

I get the error Coordinate type not loaded for library selmer/selmer in coordinate nil from my top-level deps

I’m not sure if that’s the same problem with my module deps.edn. I would expect the same error if it were

have you tried to require your top project from another one?

to see if that works?

for example one folder up from where your top depsedn is:

clojure -Stree -Sdeps '{:deps {your-top-project-name {:local/root "your-project-folder-name"}}}'

I have a test that does something like this to make sure I make the necessary exclusions etc. in my submodule depsedns

perhaps that isn't relevant in your case though

actually my top level module fails on cli also

😕

even with my alias

better sort that out first then

ok, that’s because the alias value is only pulled from the initiating root deps.edn

so that makes sense, that’s consistent across cursive and cli

Are you using the latest version of tools.deps? Because I've seen the same error when I used some old version.

@U09R86PA4 Yes, my understanding is that aliases are never transitive in deps.

I’m not quite clear after all that - are you still seeing differences between Cursive and CLI?

yes

the original scenario is still different

That scenario is a root deps.edn file which references dependencies using relative roots outside that project’s dir, correct?

It might be via an alias only, I’ll narrow it down

Ok, thanks, I’d appreciate that.

but basically, yes, {:deps {foo {:local/root "../foo"}} -> "Manifest type not detected when finding deps for foo in coordinate {:local/root "../foo"}"

ok, the key is an alias

{:deps {foo nil} :aliases {:default {foo {:local/root "../foo"}}}}

clojure -A:default -Spath is fine with this

cursive is not fine with it, even though this alias is checked in the deps tool window

Is the problem when importing the project, or when running?

so I think that may just be my expectations

no, importing

Ok, thanks, I’ll try that out.

that “manifest type not detected” error is shown when importing

this is less clearly a bug and more an expectation that those aliases are applied at import time

which is…kinda iffy

They definitely should be - that’s what the aliases tree in the deps tool window is for.

but how would you apply the alias before you import it?

basically I’m just encountering sharp edge after sharp edge trying to do monorepo-style setup with a common alias with :default-deps and :override-deps for the whole repo

So when importing, I call tools.deps.alpha directly, and I pass it the aliases I want to use for project resolution.

but how would the aliases appear in the tool window if the project isn’t yet imported? the aliases are not known yet

Yes, you have to import once for Cursive to know about the aliases, then you can select them and reimport.

Is the problem that the project is somehow invalid without those aliases applied?

well, it has unresolveable coordinates

I see you have {foo nil} in your repro case.

Hmm, I see, perhaps that’s the problem then.

the alias is needed for :default-deps in order to fill that nil in

If you can never resolve the project without the aliases, then you can’t set it up correctly in Cursive. Hmm…

now in this case, I do have the alias available in the tool window

because I happened to have other modules which didn’t depend on any local roots

Actually, wait - IIRC I actually get the aliases by reading the deps.edn directly, not by resolving the project - that should work.

but I do point it out as a UI chicken and eg problem with this approach

ah, ok

I’d have to go back and check that.

But I think that’s right.

Perhaps when importing the project, Cursive should read the deps file, find the aliases, and then allow them to be selected during import.

I guess? I’m not sure how :default-deps can work otherwise, since by definition these deps must be unresolveable unless an alias is applied

but :default-deps is clearly very rarely used; I’m not even sure if it’s appropriate here, I’m just trying to replicate something that worked like this before

actually this will be a problem with any :*-deps

so nevermind there

any “parent” type setup needs an alias to work

because only aliases can apply default and override deps

Yes I think you’re right about that. It’s true that this will apply to extra and override deps, but generally the project will still import correctly without them, and can then be reimported after the aliases are selected. The problem is default-deps, without which the project is essentially invalid.

with :override-deps you can still use empty-map as a coordinate

that is in fact how Sean Corfield uses it in his monorepo setup

Hmm, ok.

Ok, I’ll fix this.

I think that presenting the aliases during project import is the only sensible way to handle it.

I guess however that this might also be a problem if you add a new alias with override or default deps to an existing project.

I’ll test that too.

Getting the feature set combination of lein/maven parent, managedDependencies, and :local/root is pretty tough

I’ve filed this: https://github.com/cursive-ide/cursive/issues/2285. I’ll update it once I have repros of the various cases.

OK I have a minimal reproducer

interestingly, depending on whether I have the alias checked, I will get different errors

updated ticket

thanks for your help

Ok, you can work around the Manifest type error by explicitly specifying :deps/manifest :deps.

in each :local/root coordinate?

Right.

{:override-deps {bar {:local/root "../bar" :deps/manifest :deps}}} - I think this should work.

success!

I suspect that problem is because the CWD is not set correctly in Cursive.

I wish deps.edn were a bit more CWD-independent

Oh, so do I.

Although that’s a failing of many build tools, including lein.

yeah, true

I think it’s nearly there though

I have to do some truly awful things to get lein to work in Cursive.

Deps does actually have a mechanism now for manually relocating, it’s possible I’m not doing that everywhere.

:deps/manifest :jar doesn’t seem to work as a workaround for :local/root "foo.jar"