Add yank or register(.., force=true) options

[IanButterworth]

Not functionality to be advised generally, but it would be nice to add the ability to yank a release, or force re-register the current version

[haakon-e]

I was looking for functionality like this today in a private registry I use.

There I had accidentally registered a package with incorrect arguments to register(...), and would have liked to just pull the release or forcefully re-register with different arguments (in my case a different repo address).

I eventually resolved it by pushing a new version, so no big deal.. But this would've been convenient.

[aplavin]

Totally agree, forcing a registration, even of different content for the same version, would really be convenient for private registries! Any plans for that, or would such a PR be accepted? @GunnarFarneback

[jonas-schulze]

This would be a handy feature. Please let me describe my (intended) use case.

TL;DR: I would like to re-register *-dev versions of a package.

---

I am still quite uncertain about how I should develop Julia research codes. My employer requires a certain level of code review before any code is published. This means that essentially all code is first developed on an internal GitLab. Usually, I have two repositories per research project: one library and another project using that library. Both are intended to be published eventually, but I would prefer to not reveal/include the URL to the internal repository in, e.g., the Manifest.toml of the project using the library. Revealing the Git hash is fine, as I aim to have the Git histories be identical in between the internal and the released branches. Currently, I do one of the following:

1. Clone the library at ../MyPackage.jl and pkg> dev ../MyPackage
2. Add a Git submodule at ./src/MyPackage.jl

The first option does not reveal any internal URL, but it is quite brittle in that it requires the user (or anyone trying to reproduce my computations) to repeat the same process, and that it requires me to properly document which version of the library I had used at any point in time ... and I wouldn't trust me myself. The Manifest.toml may include the git-tree-sha1, but only if I run pkg> resolve regularly ... which I don't.

The second option properly documents the version of the library, but it reveals the internal URL inside .gitmodules. After my codes have passed the internal review, and just before/during publication of the code, I replace the internal URL by a public one (either publicly on GitHub or a different project on our GitLab). If someone else tries to reproduce the most recent results, this should work 🤞. If, however, someone tries to reproduce some older commit of the project that had thus far only been tested internally (for example, because the second version of the library has been developed internally again), that someone needs to adjust .gitmodules. This is beyond the average user's knowledge of Git ... at least at my employer.

One solution would be to be liberal with release candidates *-rc1, *-rc2, etc. However, I'd rather not register all these intermediate versions in General as well (the goal is reproducibility after all). Alternatively, I could register a 1.0.0-dev version over and over again. This way, I only need to pkg> add MyPackage@1 and it would pick that *-dev version.

A downside of this approach would be that the user still has to pkg> resolve or similar to fix the situation that the *-dev version is not registered in General. My hope is, though, that the error messages of pkg> instantiate are straight-forward enough, such that the user can resolve this issue 100% from within a Julia prompt.

As usual, I feel like I am overthinking this. How would you approach my problem? I am currently the only one developing with Julia in my group. If you have been reading this far, thank you.

---

Making things more difficult, it is not possible to pkg> add [email protected], because Pkg would parse this as a version range (ArgumentError: invalid base 10 digit 'd' in "dev"). 🙃

[aplavin]

Unless I'm missing something, you can just register multiple versions (like 0.1, 0.2, 0.3, ...) in you private/local registry, and only register 0.4 in General when you are ready. Then repeat: a few "dev-only" versions in local registry, some next version in General.