How to register/update my package with some local packages

I’m developing a package (called HydroModels.jl) and when I want to register this package some problems arise

The project.toml of the project is as follows:

name = "HydroModels"
uuid = "7e3cde01-c141-467b-bff6-5350a0af19fc"
authors = ["jingx <50790703+chooron@users.noreply.github.com>"]
version = "0.3.0"

[deps]
ComponentArrays = "b0b7db55-cfe3-40fc-9ded-d10e2dbeff66"
Graphs = "86223c79-3864-5bf0-83f7-82e725a168b6"
HydroModelCheckers = "1fd97331-b0fb-49c5-b501-b29cc8959555"
HydroModelCore = "7efcb156-82fb-4ff2-92b5-82bb75f40fa9"
HydroModelOptimisers = "ba5228b9-ba40-4fc8-b725-31ff0f22b938"
HydroModelSolvers = "7d7d05a4-671b-4a2b-ac7e-9f89833e42b4"
HydroModelWrappers = "ae589b45-306e-44b4-bf21-d9ef39de3338"
LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"
LinearSolve = "7ed4a6bd-45f5-4d41-b270-4a48e9bafcae"
Lux = "b2108857-7c20-44ae-9111-449ecde12c47"
MLUtils = "f1d291b0-491e-4a28-83b9-f70985020b54"
ModelingToolkit = "961ee093-0014-501f-94e3-6117800e7a78"
NNlib = "872c559c-99b0-510c-b3b7-b6c96a88d5cd"
Random = "9a3f8284-a2c9-5f02-9a11-845980a1fd5c"
Reexport = "189a3867-3050-52da-a836-e630ba90ab69"
RuntimeGeneratedFunctions = "7e49a35a-f44a-4d26-94aa-eba1b4ca6b47"
SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
StableRNGs = "860ef19b-820b-49d6-a774-d7a799459cd3"
SymbolicUtils = "d1185830-fcd6-423d-90d6-eec64667417b"
Symbolics = "0c5d862f-8b57-4792-8d23-62f2024744c7"
TOML = "fa267f1f-6049-4f14-aa54-33bafae1ed76"

[sources]
HydroModelCheckers = {path = "lib/HydroModelCheckers"}
HydroModelCore = {path = "lib/HydroModelCore"}
HydroModelOptimisers = {path = "lib/HydroModelOptimisers"}
HydroModelSolvers = {path = "lib/HydroModelSolvers"}
HydroModelWrappers = {path = "lib/HydroModelWrappers"}

[compat]
Aqua = "0.8"
CSV = "0.10"
CUDA = "5"
ComponentArrays = "0.15"
DataFrames = "1"
DataInterpolations = "8"
DifferentialEquations = "7"
ForwardDiff = "0.10"
Graphs = "1"
HydroModelCheckers = "0.1"
HydroModelCore = "0.1"
HydroModelOptimisers = "0.1"
HydroModelSolvers = "0.1"
HydroModelWrappers = "0.1"
LinearAlgebra = "1"
LinearSolve = "3"
Lux = "1"
MLUtils = "0.4"
ModelingToolkit = "9"
NNlib = "0.9"
Random = "1"
Reexport = "1"
RuntimeGeneratedFunctions = "0.5"
SciMLSensitivity = "7"
SparseArrays = "1"
StableRNGs = "1"
Statistics = "1"
SymbolicUtils = "3"
Symbolics = "6"
TOML = "1"
Test = "1"
Zygote = "0.7"
cuDNN = "1"
julia = "1"

[extras]
Aqua = "4c88cf16-eb10-579e-8560-4a9242c79595"
CSV = "336ed68f-0bac-5ca0-87d4-7b16caf5d00b"
CUDA = "052768ef-5323-5732-b1bb-66c8b64840ba"
DataFrames = "a93c6f00-e57d-5684-b7b6-d8193f3e46c0"
DataInterpolations = "82cc6244-b520-54b8-b5a6-8a565e85f1d0"
DifferentialEquations = "0c46a032-eb83-5123-abaf-570d42b7fbaa"
ForwardDiff = "f6369f11-7733-5829-9624-2563aa707210"
SciMLSensitivity = "1ed8b502-d754-442c-8d5d-10ac956f44a1"
Statistics = "10745b16-79ce-11e8-11f9-7d13ad32a3b2"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
Zygote = "e88e6eb3-aa80-5325-afca-941959d7151f"
cuDNN = "02a925ec-e4fe-4b08-9a7e-0d78e3d38ccd"

[targets]
test = ["Test", "Aqua", "CSV", "DataFrames", "Statistics", "DataInterpolations", "DifferentialEquations", "SciMLSensitivity", "CUDA", "cuDNN", "Zygote", "ForwardDiff"]

These extension libraries are stored in the lib folder for easier management. However, based on the error message, it seems I still need to register these packages (which I don’t want to do, as it would make maintenance more difficult). So, I’d like to ask if it’s possible to register a package while including some local, unregistered packages, and if so, what is the registration method? Alternatively, is there a better way to manage these packages here?

I have never heard of such a feature (but that is no guarantee that it doesn’t exist), so I think that you will need to either reorganise your code so that the included packages become submodules or you have to register them separately (If they meet the requirements for this). You could also make your own registry with LocalRegistry.jl which does not have this limitation on its dependencies, but in this case, do test it on a different computer to see if what you have done really works, or if it just happens to work because you only tested it on one computer.

The [sources] section basically has no effect in a main Project.toml file (which isn’t usually instantiated directly, but only declares project metadata). See this last sentence in the docs:

Note that this information is only used when this environment is active, i.e. it is not used if this project is a package that is being used as a dependency.

Sorry, not possible. You can make them submodules, or independent, registered packages.

OK, I’m going to register the packages in lib as new files. Thanks to GHTaarn and goerz for your suggestions.

1 Like

I would recommend creating a GitHub Organization (maybe JuliaHydroModels) to host all these packages, instead of tying them to your personal user account. That way, you can have additional co-maintainers, and it’s not such a problem if you ever step back from the project.

Please make sure that every package has at least a README that explains the purpose of the package and how it relates to the main HydroModels.jl.

Assuming each package is ready for registrations, you may want to consider manually preparing a Pull Request (with the help of LocalRegistry package) that registers all of them in one go (actually, don’t: Gunnar’s suggestion is a far better approach) . Otherwise, you have to deal with registering them in the order of their dependency graph, with a three-day period for each package.

I would not recommend a manual pull request since AutoMerge won’t run in that case, and it’s way too easy to miss something important like a license file.

If the dependency chain is long, a better way to avoid sequential waiting periods is to register all of the packages at once. AutoMerge will fail with the ones having missing dependencies, but you can re-register to retrigger AutoMerge once their dependencies have been merged into the registry. If you haven’t changed the version number (and name/uuid/url), the same PR will be updated and the waiting period will not be reset.

2 Likes

HydroModels.jl only really needs HydroModelCore.jl, which has some abstract types and methods. Stuff like HydroModelSolvers.jl and HydroModelOptimisers.jl just adds extra computing power to HydroModels.jl—they’re not must-haves, and there’s no back-and-forth dependency between them and HydroModels.jl.

I was worried that these extra libraries would drag in big SciML stuff like DifferentialEquations.jl and Optimization.jl, slowing down HydroModels.jl when it loads (or at least making it heavier). That’s why I made them separate libraries instead of sticking them inside as modules.

Right now, I’m thinking of bundling everything in the lib/ folder—except HydroModelCore.jl—into one library called HydroModelTools.jl and registering that on its own.

At first, I put HydroModelSolvers.jl, HydroModelOptimisers.jl, and others in the lib/ folder, copying how Lux.jl does it. But honestly, it’s been trickier to manage than I expected.

So, I’ve settled on having three libraries: HydroModels.jl, HydroModelCore.jl, and HydroModelTools.jl. Down the road, I might add a HydroModelLibrary.jl for some example setups.

For now, it’s just me keeping these projects going. I’ll think about making a group like JuliaHydroModels if others jump in later.

In my case, after grouping some tools together, the dependencies are pretty simple—both HydroModels.jl and HydroModelTools.jl just need HydroModelCore.jl. So, I’m probably gonna register them one by one for now.

Thanks again for the advice! It’s really helped me figure things out as a newbie to Julia packages.

1 Like