# Current best practices for depencency management for registered packages

**URL:** <https://discourse.julialang.org/t/current-best-practices-for-depencency-management-for-registered-packages/20376>\
**Category:** Tooling\
**Tags:** question\
**Created:** [February 2, 2019, 9:33am UTC](https://discourse.julialang.org/t/current-best-practices-for-depencency-management-for-registered-packages/20376 "2019-02-02T09:33:51Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 4, 2019, 11:18am UTC](https://discourse.julialang.org/t/current-best-practices-for-depencency-management-for-registered-packages/20376/12 "2019-02-04T11:18:51Z")

</div>

> [@gcalderone](#):
>
> But to register it you should throw away those files and prepare a `REQUIRE` file instead. Am I the only one finding this unintuitive?

Not at all. See eg [this issue](https://github.com/JuliaLang/METADATA.jl/issues/19416); it is unfortunate that it was closed without a solution.

Also, you may be interested in

> <https://github.com/JuliaLang/Pkg.jl/issues/849>
>
> Before we can move from METADATA being the source of truth for registered packag…es to JuliaRegistries/General being the source of truth, we need a process and infrastructure for registering packages. Here's an outline of some of my thoughts on what the process should look like.
> 
> \### 1. Request
> 
> \*\*Who: package maintainer\*\*
> 
> Package maintainer proposes a new version tag
> \- perhaps via an API endpoint?
> 
> Possible data to include:
> \- uuid
> \- repo url
> \- branch
> \- tree hash
> \- commit hash
> \- version number
> 
> Or maybe just one of \`patch\`, \`minor\` or \`major\` and version number is automatic based on existing version numbers. This is almost certainly too much data but I wanted to mention all the possible info one might want. Ideally we'd like to automate as much of this as possible from the repo.
> 
> \### 2. Check
> 
> \*\*Who: automated\*\*
> 
> Automated validation of whether a proposed version tag is acceptable.
> 
> Check that:
> \- version number is sensible (next patch, minor or major)
> \- install the package version by itself
> \- run the tests for the installed package
> \- test variations on dependencies
> \- check if compat claims are plausible
> \- reverse dependency testing
> - check semver compliance?
> 
> Produces report of results
> 
> \### 3. Review
> 
> \*\*Who:\*\*
> \- \*\*package maintainer\*\* (always)
> \- \*\*registry manager\*\* (sometimes)
> 
> Maintainer review:
> \- accept or reject based on report
> 
> If maintainer accepts, go to registry manager review:
> \- if meets auto-approval criteria, it is fully approved without manual review
> \- otherwise proposer can request manual review from a registry manager
> - abilities needed:
> - maintainer to give reasoning
> - manager to give feedback
> - manager to make a decision
> - probably good to take place on a PR somewhere
> 
> \### 4. Tagging
> 
> \*\*Who:\*\*
> \- ideally \*\*automated\*\* via GitHub API
> \- otherwise manually done by \*\*package maintainer\*\*
> 
> Propagate git tag to package repo
> \- should used signed tags signed by some authorized entity
> 
> Can we use the github API to create tags automatically?
> \- https://developer.github.com/v3/git/tags/#create-a-tag-object
> \- perhaps an app that only requires that permission
> 
> What would the workflow be for non-github packages?
> \- even if it’s very manual, we should have one
> \- have a git repo endpoint that we create tags at
> - then document how to pull tags from it?
> 
> The tagged tree also needs to be publicly accessible but I think tagging guarantees that in git. If the tag does not match the version approved in the review step above then the version is not properly tagged and the rest of the process is blocked until the tag is fixed.
> 
> \### 5. Registration
> 
> \*\*Who: automated\*\*
> 
> Once a new version has been approved and tagged, it can finally be registered. This consists of making the appropriate updates to the registry repo. This will be completely automatic.

My impression is that the current setup is considered a collection of temporary measures, so no one feels like documenting it. The best source is [this discussion](https://discourse.julialang.org/t/the-current-metadata-release-process/16672), but it hard to find for newbies. I asked my questions because I noticed some PRs in the related code checking the `Project.toml`, and I was curious.

---

_[View the full topic](https://discourse.julialang.org/t/current-best-practices-for-depencency-management-for-registered-packages/20376)._