LocalRegistry.jl is nice, but I’m wondering if the effort required to maintain a local registry could be reduced even further by using Gitea’s Package Registry.
You can see the currently supported registries (npm, PyPi, etc.) and the implementations here: gitea/modules/packages at main · go-gitea/gitea · GitHub.
Could this avenue hold some promise?
As I’m not using Gitea it wouldn’t help me at all but I’m curious what kind of maintenance improvements you’re envisioning.
For people with Gitea set up, I’m thinking the ideal would be that pushing a commit to a repo that bumps version in the Project.toml and uses a hypothetical julia package registry would automatically trigger a new release in the registry.
i.e. zero-effort releases.
I’m not sure if this is easily possible or not, but the idea is alluring…
That’s possible to do with CI scripts today. At work I have set up Julia repositories with a julia registration job which is activated on merge to master after all other jobs have passed, which calls LocalRegistry to register a version. If Project.toml wasn’t updated, nothing happens, and if it was bumped a new version is registered.
This doesn’t mean integration with a git hosting service’s package repository functionality would be meaningless, but it’s more a question of simplifying/streamlining CI setups than enabling easier workflows.
Are you using GitLab or GitHub? Do you mind sharing those workflows? I still have a few problems to solve. For example, merge requests are created nicely when I register a new package (by hand, via LocalRegistry) but the merge requests on our GitLab instance is apparently waiting for something to finish, so I always have to cancel the auto-merge first and the merge manually.
See Julia and Gitlab self-hosted : a state-of-the-art? - #6 by GunnarFarneback for some details on my GitLab setup.