Yes, new versions will need Project files in order to be registered with Registrator. No, we don’t currently have a way to autogenerate these. I think @iamed2 might have a tool for that? If not, I might be able to whip something up by then since we do have the necessary data in the registry already to some extent. Getting the dependency version bounds right is the tricky part…
Yes, after this you can just generate a random UUID as the lord intended.
3 Likes
I have two questions:
- what if my package currently only has REQUIRE. Will it still be installable on monday?
- From the docs it is not fully clear for me howto tag a release. Registering is done using a PR or issue, but how is tagging done?
When this happens, we (Invenia) will not be able to have private packages depend on versions of packages only released in General. This is because our process uses our fork of METADATA.jl as a single source of truth, and generates our private registry with it, including the (mandatory) version bounds. So even though we use the General registry, our package compat will be bounded at the versions that exist in METADATA.jl.
We may be able to overcome this somehow by reading versions from General, but we’re currently looking into how feasible that is (as of like 5 minutes ago).
Ideally we can register privately but the person who was supposed to be looking into that has been away. Based on the code in https://github.com/JuliaComputing/Registrator.jl/blob/master/src/register.jl#L115 it doesn’t seem like it will be that hard though?
Yes, anything that is installable now will continue to be installable on all versions of Julia. This change only affects registering new versions of packages. If you don’t maintain packages or don’t plan to make any new releases any time soon, you don’t have to worry about it until you do. The warning is mostly so that package maintainers who do want to release new versions of packages are aware that there will be a new process and it may be a little bit rough. Don’t plan things so that it’s crucial to your life to get a new version of something released on Monday.
From the docs it is not fully clear for me howto tag a release. Registering is done using a PR or issue, but how is tagging done?
@Nishanth_Kottary, care to field this one?
I do not have a tool to autogenerate Project.toml from REQUIRE, but @oxinabox might?
Apparently it was Curtis and the thing kind of almost works and only in 1.0: Generate an almost-right Project.toml file from a REQUIRE file in Julia 1.0 <= VERSION < 1.1- · GitHub
4 Likes
I tried it out, but didn’t see any notifications or status of my request? Where’s the General registry fork located at?
Some of the things mentioned in the Registrator README isn’t enabled (to keep things simple) so that might not be the best guide. I would suggest reading the instructions from here: https://juliaregistrator.github.io.
Tags and releases are not required for the registration process. It is up to the user to create them if they want them.
2 Likes
I tried it on a small project and made various mistakes which the bot pointed out with helpful error messages. Registrator test · Issue #12 · c42f/FastClosures.jl · GitHub
Looks very nice so far!
2 Likes
Is this a good example of the Registrator workflow, just so I don’t misunderstand the stuff. I couldn’t find a complete description of the workflow.
Creating a new package:
(1) Create a new package using these instructions in the pkg docs.
(2) Work on the code until you are satisfied, and do commits as you like.
(3) Change the version number in the Project.toml file to one you like, or keep it. Then make a commit and comment on that one with “@JuliaRegistrator register()”. Wait until the maintainer accepts the pull request. (Here there are options using PRs and issues too).
(4) Optionally: Tag a release on github that matches your version number in Project.toml file.
Creating a new version release of an existing package by repeating step 3 and 4.
Is this a good way to do it? Does this mean that the maintainer of General will have to accept the PR for each new version release too, not only new packages? Thanks for feedback.
1 Like
Yes, this is the idea.
We will soon have auto merging of PRs on General through CI without human intervention.
1 Like
I still do not get it. Registration is clear. But how do I make versions? Is now the version in Project.toml relevant? It was not before.
2 Likes
Oh so the way to set the version is to add it manually to the project.toml file?
Yes, the version = ... field in the Project.toml file is the version number.
2 Likes
And then @JuliaRegistrator register() to make a release? Or what is the term register has to be replaced by?
1 Like
I cannot find the term version in the readme. From reading that document it also is not clear for me that register will make a release. I would either suggest using two different terms for registration and release making or name the entire thing publish which would cover both cases. I recall it was once called publish in the PkgDev days.
2 Likes
IMHO both “registering a new release” and “publishing a new release” sound ok, but I’d also prefer the latter choice (mostly because it’s what npm uses, which obviously isn’t a great argument).