There are not tags for SnoopPrecompile in the repo

[davidanthoff]

JuliaFormatter has taken a dependency on SnoopPrecompile, and so now we need to ship that with the VS Code extension. The mono repo structure here makes that quite a bit more involved, and that there aren't any tags in the repo that correspond to the registered versions really hard to integrate with the way the extension ships packages. Is there a chance that tags could be added somehow?

CC @pfitzseb, @domluna

[timholy]

It would be great if TagBot could handle subdir packages. I don't think it does. CC the greatly-overworked @DilumAluthge in case he knows something.

Failing that I suppose we could add them manually. Happy to grant commit access if someone wants to do it.

[davidanthoff]

Thinking about it, not even clear to me how this would work, though :) Different packages in this repo could have the same version, so the tags then presumably couldn't just be semver strings, but something else? Or are these packages all tagged in synced and always have the same version, and that is the reason for the mono repo?

[DilumAluthge]

There's a PR open to add subdir support to TagBot: JuliaRegistries/TagBot#252

The only reasonable strategy for tags to work with subdir packages if you prefix the tag with the package name.

e.g. Foo-1.2.3, Bar-4.5.6

[davidanthoff]

Feel free to just dismiss this: but is this mono repo thing actually buying much? Wouldn't it just be easier to follow the normal model of one repo per package? It would certainly make it easier to find things, easier for contributors that aren't familiar with this model and much, much easier for downstream users like us that have somewhat more complicated needs (the VS Code extension), plus all the tooling in the ecosystem would just work?

[timholy]

For SnoopPrecompile, it's not a big advantage. I'm actually planning to move it to JuliaLang, I just haven't had time lately.

But in other cases, mono-repos are great. It's made development of TypedSyntax/Cthulhu dramatically easier. At some point we may put much of JuliaImages in a single repo.

[davidanthoff]

For SnoopPrecompile, it's not a big advantage. I'm actually planning to move it to JuliaLang, I just haven't had time lately.

That would be awesome! That would make it much, much easier for us to use it in the VS Code extension. Happy to help, as that would unblock us from updating some packages to their latest version. If you want, I can just do this?

But in other cases, mono-repos are great.

Yep, I can completely see that it can be very useful in some situations, no argument from me :)

[davidanthoff]

Just FYI, I have a local repo now that has just SnoopPrecompile in it. If you want me, I can just push that to JuliaLang/SnoopPrecompile.jl and I think then we just need to register it.

[timholy]

I'll handle the transfer, there may be a couple of cleanups that should be done too. And it needs independent documentation. In other words, this is more than a copy-paste.

Aside from time, the other thing that holds me back is the sense that we should take the opportunity of the move as a chance to rename it. The name is a good description of what it does, but people seem (for obvious reasons) to confuse it with SnoopCompile. But I haven't yet come up with a good new name.

[timholy]

Closed due to PrecompileTools

[davidanthoff]

Fantastic, thanks :)