Fork me on GitHub
#cursive
<
2019-12-16
>
bortexz11:12:15

Has someone seen this error before?

Module property-manager is managed by Maven and cannot be managed by Leiningen at the same time.

imre12:12:05

have you tried re-importing the project?

bortexz13:12:42

^ Yes, that ended up solving it. I was wondering if there would be a way to change that without reimporting

favila14:12:39

is there an issue with relative paths in deps.edn files? I’m getting "manifest type not detected when finding deps for …. in coordinate :local/root "../stuff" or "../myjar.jar". The deps files are one level down from the project root. The clojure tool seems to handle this

favila14:12:25

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

favila14:12:35

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

imre14:12:33

I have such a project and it is working alright

imre14:12:23

using IJ 2019.3 and Cursive latest eap

imre14:12:08

1.9.1-eap1-2019.3

favila14:12:14

ok, I’m on 2019.2.4 and not eap

favila14:12:21

I’ll try that

imre15:12:00

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

imre15:12:01

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

favila15:12:43

yes but I thought that work was released

imre15:12:07

It was, in 1.9.0

imre15:12:43

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

imre15:12:56

and haven't had any problems

favila15:12:17

tried 2019.3 and eap, didn’t help

favila15:12:20

same error

imre15:12:27

weird. Have you tried reimporting?

favila15:12:23

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

imre15:12:52

do you have a top-level deps.edn?

imre15:12:58

or just the subprojects?

favila15:12:46

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

imre15:12:03

hmm I have a top-level one

favila15:12:08

how do you do that?

imre15:12:15

referencing all sub-projects as its deps

favila15:12:32

oh, but how do subprojects reference each other?

favila15:12:48

ok, that’s what’s not working

imre15:12:07

perhaps adding a top-level deps edn could help?

favila15:12:51

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

imre15:12:17

top:

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

imre15:12:45

oops no keywords in dep names tho (fixed)

favila15:12:50

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

imre15:12:17

not sure

favila15:12:19

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

imre15:12:36

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

favila15:12:37

everything works fine from a terminal

imre15:12:32

I'm afraid my knowledge only extends this far

favila15:12:22

ah I think I understand now

favila15:12:44

well, no, actually I don’t fully

favila15:12:55

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

favila15:12:18

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

favila15:12:47

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

favila15:12:17

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

favila15:12:23

I guess the command line tool does this

favila15:12:26

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

favila15:12:50

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

imre15:12:59

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

imre15:12:07

to see if that works?

imre15:12:24

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

imre15:12:16

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

imre15:12:24

perhaps that isn't relevant in your case though

favila15:12:39

actually my top level module fails on cli also

favila15:12:00

even with my alias

imre15:12:10

better sort that out first then

favila16:12:06

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

favila16:12:17

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

p-himik20:12:19

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

cfleming20:12:53

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

cfleming21:12:33

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

favila21:12:38

the original scenario is still different

cfleming21:12:30

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

favila21:12:13

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

cfleming21:12:38

Ok, thanks, I’d appreciate that.

favila21:12:28

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

favila21:12:46

ok, the key is an alias

favila21:12:37

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

favila21:12:55

clojure -A:default -Spath is fine with this

favila21:12:13

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

cfleming21:12:34

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

favila21:12:38

so I think that may just be my expectations

favila21:12:40

no, importing

cfleming21:12:50

Ok, thanks, I’ll try that out.

favila21:12:01

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

favila21:12:35

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

favila21:12:47

which is…kinda iffy

cfleming21:12:17

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

favila21:12:38

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

favila21:12:12

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

cfleming21:12:13

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

favila21:12:40

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

cfleming21:12:05

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

cfleming21:12:26

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

favila21:12:56

well, it has unresolveable coordinates

cfleming21:12:02

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

cfleming21:12:12

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

favila21:12:17

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

cfleming21:12:39

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

favila21:12:58

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

favila21:12:21

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

cfleming21:12:32

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

favila21:12:39

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

cfleming21:12:56

I’d have to go back and check that.

cfleming21:12:02

But I think that’s right.

cfleming21:12:50

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

favila21:12:22

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

favila21:12:13

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

favila21:12:36

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

favila21:12:44

so nevermind there

favila21:12:00

any “parent” type setup needs an alias to work

favila21:12:15

because only aliases can apply default and override deps

cfleming21:12:42

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.

favila21:12:36

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

favila21:12:52

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

cfleming21:12:01

Ok, I’ll fix this.

cfleming21:12:25

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

cfleming21:12:08

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.

cfleming21:12:24

I’ll test that too.

favila21:12:09

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

cfleming21:12:57

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

favila21:12:42

OK I have a minimal reproducer

favila21:12:03

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

favila21:12:31

updated ticket

favila21:12:35

thanks for your help

cfleming22:12:01

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

favila22:12:22

in each :local/root coordinate?

cfleming22:12:26

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

cfleming22:12:08

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

favila22:12:35

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

cfleming22:12:47

Oh, so do I.

cfleming22:12:07

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

favila22:12:11

yeah, true

favila22:12:21

I think it’s nearly there though

cfleming22:12:31

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

cfleming22:12:11

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

favila22:12:03

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