`add Desktop` confused by existing local directory with name of registered package

[mgkuhn]

I registered a package called Desktop.jl (provides portable functions for basic GUI Desktop interactions, namely checking for presence of GUI desktop, as well as opening URLs and files).

With hindsight that particular package name turned out to be a slightly problematic, because Pkg can get confused by the directory Desktop that many users have in their home directory:

$ cd ~
$ ls -d Desktop
Desktop
$ julia
(@v1.5) pkg> add Desktop
[ Info: Resolving package identifier `Desktop` as a directory at `~/Desktop`.
ERROR: Did not find a git repository at `Desktop`

(@v1.5) pkg> 

I found three alternative workarounds:

• change the current working directory to one that does not contain a subdirectory whose name collides with that of the registered package to be added
• use ] add Desktop.jl instead of ] add Desktop
• use Pkg.add("Desktop") instead of ] add Desktop

I was surprised that ] add Desktop behaved differently from Pkg.add("Desktop").

Perhaps it should ignore subdirectories in the current working directory that lack a Project.toml file or a .git subdirectory, just output a warning that it ignored that directory, and then move on to search the registry?

[timotaularson]

I had to go looking for workarounds like you did.

Perhaps Pkg.jl should be changed so
] add SomePackage
would prefer or only get the package from a registry,

leaving
] add ./SomePackage
as a way to specify the package should be loaded from the current local directory.
(And make the same change to pkg"add SomePackage" as well.)

It is surprising that currently the top example acts like the bottom example
when there happens to be a directory with that name present.

Even specifying a version currently does not clue it in that it should get the package
from a registry...instead it errors and informs you that you cannot use a version
when adding a local package.

[fredrikekre]

The REPL mode is sometimes ambiguous like this. In this case we look for a path first before resorting to the registry. But perhaps we could make sure the path looks like a package first.

[StefanKarpinski]

It does seem like looking for a package of that name first would be better since if you want to local path you can write ./Desktop but there's no way to do it the other way around.

[fredrikekre]

Yea, I believe we have discussed exactly that somewhere but can't find it now.

[Marco-Congedo]

see also this

[GunnarFarneback]

See #1636 and #2275 for PRs to fix this.