I get that the automated PRs to add Project.toml to all registered Julia packages alleged at Pkg3 plan and status won’t happen, right?
It seems better to have people generate project files when the register the next version of their package.
I would much prefer to somehow be able to convert all my REQUIRE files in one go at one point in time, than doing it whenever I want to tag one of my packages as needed. The latter will require me to revisit again and again what I need to do, and I’m sure I will forget the steps each time I do it… And if there is some script, or automatic PRs or something like that that helps me with that, it would be awesome.
In fact, even a one-time script that opened a PR against all the repos that have registered packages with the necessary changes would be awesome, I think.
I’m also getting the can’t find dependancy bug with CSV,
Error while trying to register: Error in `[deps]` : Package 'CSV' with UUID: 336ed68f-0bac-5ca0-87d4-7b16caf5d00b not found in registry or stdlib
Is this because the CSV maintainer hasn’t used registrator yet? How does this work?
Here’s a script that can generate a project file for a package with a REQUIRE file:
https://github.com/JuliaLang/Pkg.jl/pull/1133/files
You call it with ARGS as directories where packages live. If the first argument is -f then it will overwrite existing Project.toml files, otherwise it will refuse to do so. It generates a [compat] section that approximates the bounds in the REQUIRE file as closely as possible, but unfortunately since the [compat] section doesn’t support version ranges this translation can be a bit messy. It is strongly encouraged that you manually review the [compat] section and edit by hand as appropriate.
Oh, I should also note that this will only generate a correct project file if all of the dependencies have METADATA-compatible UUIDs. If you try to use this to generate a project file for a package that has dependencies that are not registered in General, this might not be the case and the results will be wrong. This is designed primarily to work for already-registered packages.
The sync script is still offline because of a hardware failure. I’m getting the sync script up and running on a different machine.
Awesome!
Folks should scan for PRs against that PR. I’ve already added one new feature, https://github.com/JuliaLang/Pkg.jl/pull/1134.
Your PR is Merged now.
I also got the sync script back up and running. This should in theory be easy but in practice lots of people delete packages that they’ve registered which then have to be blacklisted to be skipped and people also do things like tagging versions that are unreachable even if you clone a repo, e.g. because they started the tagging process and then changed their minds and abandoned it. So in practice, keeping this thing running is an annoying process of hunting down failures and adding special cases.
Since the hardware failure has taken the sync script offline at a bad time and thereby delayed the switchover process, and since people seem to be actively contributing to the script that generates project files, it seems like it may be better to wait a bit before pulling the trigger on switching over to the new registration process, although I could be convinced otherwise.
I’ve also looked into making pull requests automatically to add project files to packages that don’t have them. However, there are some issues.
-
GitHub does not like it when people do this from personal accounts—see the last point in New tools for open source maintainers | The GitHub Blog — @staticfloat did this previously to update a lot of travis scripts but got in some hot water for it.
-
The approved way to do this seems to be create a GitHub integration, which is pretty heavyweight—it’s annoying to do from the developer perspective and needs to be added to the relevant package repos by developers, at which point it doesn’t seem that much easier than running a script locally for a one-time benefit.
In the end, I’m pretty sure that between the difficulty of getting an integration working correctly and people having to add the integration to their repos, this is more work and less reliable than just having package maintainers check out their own package repos and running the script I wrote on them. After doing that, developers can inspect the results locally and push the changes if they look good.
Note that GitHub has no issue with people doing automated actions on their own repos (they explicitly call this out as acceptable in the above article), so if someone wants to script that with the hub tool or something, that could be something that people with many package repos could use.
Is it inappropriate to cheer you all on while you keep making julia my favourite language?
No, it’s very much appreciated 
. I will be quite happy when this switch is done. The process has been far too long and annoying…
Seconded 
This delay has been annoying, but I continue to be grateful that the emphasis is on trying to do things right rather than to do them fast.
I quite often do a release, then have to edit it, but in my defense I do actually delete the release and tag and make it again. Is there functionality for editing releases in JuliaRegistrator?
There is not because the process is different: no release is made or tagged until after everything is verified, approved and registered. By design, there is no need to replace releases. This is what makes it different than attobot and why tagging is done after approval (what @juliohm and @chakravala are unhappy about above).
I’ve decided that ultimately it is a problem with GitHub’s workflow: they have a review process and evaluation process for changes (Pull Requests), but not for releases. The deleting/retagging thing shouldn’t generally happen.
Right, avoiding retagging was one of the design goals of the new process.
Awesome work, thanks! 
Just FYI I copy-pasted the tag generation code given to me by Registrator into a terminal in my repo, and it resulted in a malformed tag that prevented me from using my git client (GitKraken) until I’d deleted the tag again. I think it might be related to the fact that my repo was moved to an org in the past and my local origin still pointed to the old location (github forwards it, but that appeared to not work for the tag). The git CLI still worked. Took me a few days to find out what the trouble was.
I think I’ve lost the plot. Has the switch over been delayed, and to what date?
The switch has been delayed to an undefined date.