Allow registering packages in a subdir of the main repo directory

[KristofferC]

With JuliaLang/Pkg.jl#1422 someone can install a package that lives in a subdirectory of a repo. For the complete "subdir-experience" we should also allow registering packages that live in a subdirectory.

I would suggest the API @JuliaRegistrator register subdir=path/to/Package.

Note that the tree-sha that gets registered in the registry should be that of the path path/to/Package not the tree-sha of the main directory of the repo itself.

[JuliaRegistrator]

Registration pull request updated: JuliaRegistries/General/3966

After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.

This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:

git tag -a v1.0.0 -m "<description of version>" 256fda989fa128702c86142d30f555f39750ecd0
git push origin v1.0.0

[KristofferC]

[fingolfin]

I really really like this, together with #1251, so we can have multiple Julia packages in one monorepo.

As an extension of what is suggested here, would it perhaps be acceptable if in addittion a command like ... register all (or whatever) is added, which searches all Project.toml files in the repository (alternatively: all one level down; all at most N levels down; ...) and registers each of them? That would be quite convenient.

One might think of variants, like ... register subdir=*, possibly even allowing generic globs / regex; but to me the main uses are updating either a single package, or all of them. While I wouldn't object to more flexibility if somebody thinks that's useful, I'd personally focus o these two usecases first.

Spinning this further, perhaps registering multiple subdir-packages at once could even result in a single registry PR that updates all of them at once? That would be handy if they really ought to be used in matching versions.

[KristofferC]

While those extensions sounds reasonable, I think we should first have the simplest case with one package at a time working first. Then we could do something like subdir= *

[GunnarFarneback]

Notice that the tagging story becomes different in the subdirectory scenario. It's not obvious how the tags on the repository should relate to the versions of one or more Julia packages in various subdirectories, if at all.

[fingolfin]

One idea would be to use different tag names for package in subdirs: e.g. subdir-v1.2.3 ; or PackageName-v1.2.3. While unprefixed v1.2.3 is reserved for the package in the rootdir (if there is any).
Of course that would mean that one gets a bunch of tags if releasing multiple subdir packages at once...

[DilumAluthge]

One idea would be to use different tag names for package in subdirs: e.g. subdir-v1.2.3 ; or PackageName-v1.2.3. While unprefixed v1.2.3 is reserved for the package in the rootdir (if there is any).

I like this system.

[fredrikekre]

The name of the tag does not really matter but I think it would be good to standardize it such that tools like Documenter, that inspect tags for building docs, can understand them.

I think ${NAME}-${VERSION} is a nice format. That was, for example, used by Yggdrasil: https://github.com/JuliaPackaging/Yggdrasil/releases

[DilumAluthge]

The name of the tag does not really matter but I think it would be good to standardize it such that tools like Documenter, that inspect tags for building docs, can understand them.

Yes, we should definitely have a standardized naming convention.

I think ${NAME}-${VERSION} is a nice format. That was, for example, used by Yggdrasil: https://github.com/JuliaPackaging/Yggdrasil/releases

Sounds good to me.

[fingolfin]

Just to be explicit about it: with ${VERSION} you mean the version plus a v prefix, right? That's what I see in Yggdrasil, too. So we agree, great.

Question: should the name of subdirectory be required to match the package name? Right now, I think nothing requires that. Makes me wonder: is the repository name expected to match the package name right now? I never tried differently...(To be clear, I am not saying this should be done; I expect it'll be easier to not enforce this. But if anybody sees a good reason for this match, it'd be more difficult to enforce it retroactively.

For my use cases, package and subdir name will always match, so I really don't mind either way ;-)

[fredrikekre]

I believe that we check that the repo name matches the package name for automatic merging so that would be relaxed. I still think it might be good to check that the directory is named the same as the package.

[GunnarFarneback]

If you have a larger repository where the Julia package is just a part, it's quite possible that you want the Julia package to live in, say, the julia directory. Having to add another directory level just to match the package name would be annoying.

[DilumAluthge]

Yeah we have to think about what changes we need to make to AutoMerge.