Julia 1.4 fails to add local package

With Julia 1.3.1 I can add a Julia package which is hosted on my local git server with IP by doing

pkg> add "user@"

In Julia 1.4.0 and 1.4.1 the above throws the error

ERROR: Path `user@` does not exist.

Did the syntax for add change between 1.3.1 and 1.4.0? I couldn’t find anything to that respect in the docs.


1 Like

Looks like a bug to me, please open an issue. Note that you can always use the non-ambigous syntax outside of the Pkg REPL mode

using Pkg
Pkg.add(PackageSpec(url = "user@"))

Yes, but unfortunately

using Pkg
Pkg.add(PackageSpec(url = "user@"))

fails as well with

julia> Pkg.add(PackageSpec(url = "user@"))
ERROR: Path `user@` does not exist.
 [1] pkgerror(::String) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.4\Pkg\src\Types.jl:53
 [2] handle_repo_add!(::Pkg.Types.Context, ::Pkg.Types.PackageSpec) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.4\Pkg\src\Types.jl:558
 [3] handle_repos_add!(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.4\Pkg\src\Types.jl:620
 [4] add(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}; preserve::Pkg.Types.PreserveLevel, platform::Pkg.BinaryPlatforms.Windows, kwargs::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.4\Pkg\src\API.jl:139
 [5] add(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.4\Pkg\src\API.jl:112
 [6] #add#27 at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.4\Pkg\src\API.jl:109 [inlined]
 [7] add at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.4\Pkg\src\API.jl:109 [inlined]
 [8] #add#23 at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.4\Pkg\src\API.jl:106 [inlined]
 [9] add(::Pkg.Types.PackageSpec) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.4\Pkg\src\API.jl:106
 [10] top-level scope at REPL[5]:1


Will open an issue.


Okay thanks, the problem is that we don’t interpret that as a url:

julia> Pkg.Types.isurl("user@")

I guess something else changed to 1.4 which made this problem apparent.


Pkg.add(PackageSpec(url = "ssh://user@"))

That seems to work for me.

1 Like

@pixel27 Thanks for the hint. I assume there is a typo. Your proposal works for me, if I replace the colon between IP and package name by a slash:

Pkg.add(PackageSpec(url = "ssh://user@"))

this also works directly in Pkg like this

(@v1.4) pkg> add "ssh://user@"

After some trying in Julia 1.3 and 1.4, I get the following results:

(v1.3) pkg> add "user@" -> ok
(v1.3) pkg> add "ssh://user@" -> ok
(v1.3) pkg> add "user@" -> Error: unsupported URL protocol
(v1.3) pkg> add "ssh://user@" -> Error: git repository not found

(v1.4) pkg> add "user@" -> Error: Unable to parse "..." as a package
(v1.4) pkg> add "ssh://user@" -> ok
(v1.4) pkg> add "user@" -> Error: Unable to parse "..." as a package
(v1.4) pkg> add "ssh://user@" -> Error: git repository not found

The equivalent PackageSpec commands behave in the same way (slightly different error messages though).

Hence, difference between 1.3 and 1.4 is that the first form in not working any longer. I am wondering whether this is a bug or is actually intended to remove ambiguity?

Is there any place where the desired behavior is documented? In the Pkg docs I could find only a subset of all options.


Not the documentation but if you read regular expressions fluently the relevant rows of the implementation (as it looks for the upcoming Julia 1.5) are https://github.com/JuliaLang/Pkg.jl/blob/fff698d3d7d90a55431ad2f4fa0af9719d899954/src/Types.jl#L37 and https://github.com/JuliaLang/Pkg.jl/blob/fff698d3d7d90a55431ad2f4fa0af9719d899954/src/REPLMode/argument_parsers.jl#L27-L54.

1 Like

Sorry yeah, that last colon should be slash…I just copied it from @kristoffer.carlsson post earlier (yes I’m passing the buck).

And I have to agree that this looks like just a change to remove any ambiguity.

Very interesting. So, in the end it seems reasonable to require specification of the protocol to eliminate ambiguity. No bug report necessary.

Thanks everyone.