The double constructor PackageSpec is very confusing

[KristofferC]

For some reason we have the struct PackageSpec in Pkg.Types but then what we export is a method with the same name

julia> using Pkg

julia> PackageSpec
Package (generic function with 4 methods)

that acts differently from the constructor to the PackageSpec struct.

This leads to very confusing things like:

julia> Pkg.develop(Pkg.Types.PackageSpec(path="Foo"))
ERROR: name, UUID, URL, or filesystem path specification required when calling `develop`
Stacktrace:
...

julia> Pkg.develop(PackageSpec(path="Foo"))
Path `Foo` exists and looks like the correct package. Using existing path.
  Resolving package versions...

[StefanKarpinski]

Seems like just a bug? I'm sure the method must have been intended as an extension of the constructor.

[KristofferC]

I think they are intentionally decoupled (see: #936)

Split PackageSpec constructor into an internal constructor and a user-facing constructor (inspired by #872). It really is two different use cases: one is "create this object and set these fields", the other needs to do hand holding and error checking.

I understand the motivation but it becomes kinda confusing when you develop.

[DilumAluthge]

Yeah I understand the use case for having two separate methods, but it's confusing that they have the same name.

E.g. it might be better if the internal constructor was named Pkg.Types.PackageSpec, and then the exported user-facing constructor was named Pkg.package_spec or something like that.