Cache is used even for local repos

[FroMage]

I currently have a module ceylon.json in my cache folder hiding my user repo published version. That's not normal is it?

I have to clear the cache now.

Sending this to @quintesse ;)

[quintesse]

It definitely shouldn't do that. But I'm not sure if this is for me or for @alesj to solve, but knowing Ales is normally very busy I'll at least take a look at it. Could you tell me what you did exactly? How and where did you publish for example?

[alesj]

@FroMage what's a cache folder vs. user repo published version?

@quintesse I guess this is the repo order issue again?

[quintesse]

@alesj It shouldn't be, but it might be something I mishandled when changing the way the repo managers get created. The cache folder is what you call the root folder. But before the root folder was the same as the user folder (so it actually got added twice) but nowadays we split them into two different folders, the cache/root is ~/.ceylon/cache while the old user repo is still ~/.ceylon/repo (but this one gets added almost as the last repo in the list, just before http://modules.ceylon-lang.org)

[quintesse]

BTW, just to be sure I'm getting this right: I'm assuming that only remote repos cache downloaded modules in the root/cache folder, right?

[alesj]

BTW, just to be sure I'm getting this right: I'm assuming that only remote repos cache downloaded modules in the root/cache folder, right?

Yes.

[alesj]

(but this one gets added almost as the last repo in the list, just before http://modules.ceylon-lang.org)

This would explain why cache is used before user repo.

[quintesse]

This would explain why cache is used before user repo

No, because the cache should not contain anything. The module already exists in user so it will never get to the remote repo so it should never store anything in the cache.

[alesj]

Ah, true.

Is there a remote repo before user repo with this module?

[quintesse]

There shouldn't be (maybe @FroMage can test with verbose and post the repo list here)

[FroMage]

The repo list is the one you get if you create a new project on the IDE. Come on, this is trivial to reproduce: just place a module foo/1 in your cache manually, with nothing in that module, then add a Foo type to it and place the new foo/1 in your user repo manually, then import foo/1 from a new project in the IDE and witness that it doesn't see the Foo type because it's using your cache repo.

[quintesse]

You see Stef, this is not about somebody being too lazy to try it, it's about needing to know exactly what you did. Because this is from the IDE, the IDE still has problems with the repo ordering so I'm not surprised to see strange things happening. So with a simple sentence you saved me hours of work trying to reproduce something on the command line that isn't there. ;)

[FroMage]

On re-reading my initial description I agree with you there was a lot of data missing, sorry :(

[quintesse]

On the CLI this was never a problem and have not been able to reproduce this inside the latest IDE so closing this.

[FroMage]

So you tried this from the CLI?

[quintesse]

From the CLI I've never been able to reproduce this problem so I assume it was an IDE issue (when the integration with the new CMR/config system wasn't complete yet)

[FroMage]

OK

[FroMage]

I just reproduced this on the CLI, it's still broken.

[FroMage]

So the problem is that the cache is located before the command-line and user repos, which can contain local repos that should be stronger than the cache, since the cache should only be for remote repos.

I think the cache should not return artifacts if the same artifacts are in command-line or user repos that are local.

How hard is that?

[FroMage]

Or as @quintesse suggested, the cache should not be a normal repo but sort of a delegate of remote repos, where they would first try the cache before trying the remote repo. This way local repos that are before remote repos would not use the cache.

[quintesse]

What do you think @alesj ? This would make the root repo something of a special item, that doesn't appear in the list (which also gets rid of the problem where we have to decide if we need to pre- or append a repository to the list, we can just append them in order and be done with it).

[alesj]

OK, I'll have a closer look.

[FroMage]

Thanks!

[alesj]

My CMR/master should have the fix.

• https://github.com/alesj/ceylon-module-resolver

Can you please try it out, and let me know if it works for you. I'll then merge it with upstream.

[FroMage]

I'll try this out this morning, thanks!

[FroMage]

I've added a test in compiler that makes sure that this works. You can merge it, thanks! Or I can merge it too if you want.

[quintesse]

Thanks Ales, looks good!

[alesj]

@FroMage np, I'll merge it, as I have a few other small fixes as well.

[FroMage]

Closing, thanks!