Pkg3: Unregistered Packages?

[rofinn]

I'm unclear as to how Pkg3 will handle unregistered packages. Is the expectation that all packages must be registered with at least a personal/private registry? Currently, it's very useful to run Pkg.clone to try out someone's changes. Similarly, declaring dependencies with just a git url in a DECLARE file provides a convenient way of developing a collection of inter-dependent packages prior to registering them.

[tkelman]

This was touched on a bit in #14 (which is long and went all over the place)

How would version resolution work on an unregistered package? Right now, unregistered packages have no versions - how would Pkg3 change that?

This is a good question. I was considering just using tags for versions in unregistered packages. But of course, you generally don't want to bother tagging versions if your package isn't registered, so I'm not sure what the point is. Instead, I think one would just use an environment file in the git repo to synchronize unregistered packages in lock-step (a la MetaPkg), but their dependencies on registered packages can be looser via compatibility constraints in the unregistered package repos.

I had a counter-proposal which was to treat registered and unregistered packages the same by way of allowing packages to contain their own registry information in a specific file (and always looking at master for the latest registry information, which would point to the specific git tags to use for the actual package code's release versions). That way there would be no such thing as unregistered packages any more but there could be "self-registered" packages which would accomplish much of the same thing, except with a method of recording enough registry data to participate in version resolution like any registered package would.

We'd have to think through either implementation, how to handle versioning / dependency resolution for packages with no registry vs how having a self-registered package might work in practice.

[tkelman]

it's very useful to run Pkg.clone to try out someone's changes

"cloning latest master" for development modifications or quick informal evaluation purposes will probably need to use a separate mechanism from the immutable, known-versions resolution system used for installing release tags of packages.