New package: SpeedyInternals v0.1.0

[JuliaRegistrator]

• Registering package: SpeedyInternals
• Repository: https://github.com/SpeedyWeather/SpeedyWeather.jl
• Created by: @milankl
• Version: v0.1.0
• Commit: 91ea402702423a0dcb309be547c9782455c2f259
• Reviewed by: @milankl
• Reference: SpeedyWeather/SpeedyWeather.jl@91ea402#commitcomment-165140488
• Description: Play atmospheric modelling like it's LEGO.

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines which are not met ❌

• There is no compat entry for julia.

• The following dependencies do not have a [compat] entry that is upper-bounded and only includes a finite number of breaking releases: DocStringExtensions, KernelAbstractions

  Extended explanation

  Your package has a Project.toml file which might look something like the following:

  name = "YourPackage"
  uuid = "random id"
  authors = ["Author Names"]
  version = "major.minor"
  
  [deps]
  # Package dependencies
  # ...
  
  [compat]
  # ...

  Every package listed in [deps], along with julia itself, must also be listed under [compat] (if you don't have a [compat] section, make one!). See the Pkg docs for the syntax for compatibility bounds, and this documentation for more on the kinds of compat bounds required for AutoMerge.

3. Needs action: here's what to do next

1. Please try to update your package to conform to these guidelines. The General registry's README has an FAQ that can help figure out how to do so.
2. After you have fixed the AutoMerge issues, simply retrigger Registrator, the same way you did in the initial registration. This will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless the AutoMerge issue is that you skipped a version number).

If you need help fixing the AutoMerge issues, or want your pull request to be manually merged instead, please post a comment explaining what you need help with or why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the public Julia Slack for better visibility.

4. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[mrufsvold]

The name of this registration -- "SpeedyInternals" -- doesn't match the repo name, "SpeedyWeather."

If you're trying to register an "Core utilities " package that is a dependency of SpeedyWeather, maybe you could name it "SpeedyWeatherInternals" so it is more descriptive?

[noblock]

[milankl]

Okay so for SpeedyInternal/SpeedyWeatherInternals we could do this but there is another 3 submodules coming we're planning to register that shouldn't follow this pattern RingGrids, LowerTriangularArrays but we would like to keep them in a monorepo. Is that a hard no for the Julia registry?

[noblock]

[vchuravy]

There is no requirement that in a monorepo all the packages have a name prefix.

[noblock]

[goerz]

I don't think it's a "hard no". Just be mindful of the shared namespace of the General registry. So if these sub-packages are useful only in the context of SpeedyWeather, you don't want to block these names more generally, and it might be better to prefix them with something unique. Maybe Speedy is already unique enough, but of course,SpeedyWeather would be the most unique, with no potential for conflict at all. Secondly, if RingGrids and LowerTriangularArrays are as general and separately useful as the name implies, then I'm not sure what the rationale is for keeping them in a monorepo. Personally, I would much prefer each package having its own repo, with the associated issue tracker etc. But then, I'm not the biggest fans of monorepos in general, so opinions on this may differ.

[noblock]

[milankl]

We want to be able to codevelop these packages without the need of registering the submodules all the time. They are standalone as the name suggests and want to provide them more generally to other users.

[noblock]

[GunnarFarneback]

[noblock]
To be clear, whether the packages are developed in a monorepo or in separate repositories is of no consequence to the registration in General. People may have opinions about the naming of the packages, but that would happen regardless of the repository organization.

[GunnarFarneback]

[noblock]
I will make a comment on the repository organization though. Best practice when you have multiple packages in the same repository is to place all of them in independent subdirectories, also the "main" package. The reason is that with one package at the top of the repository, it will be distributed with unused copies of all the packages placed in subdirectories below it.

[milankl]

with one package at the top of the repository, it will be distributed with unused copies of all the packages placed in subdirectories below it.

Okay maybe I'm still confused about how this work, but that sounds actually like what we want, we have

1. SpeedyWeather, depends on
   2. SpeedyTransforms, depends on LowerTriangularArrays, RingGrids, SpeedyInternals
   3. LowerTriangularArrays, depends on SpeedyInternals
   4. RingGrids, depends on SpeedyInternals
   5. SpeedyInternals

We currently only have 1 registered but want to register 2-5 too for general use in other projects but at the same time have SpeedyWeather main always use main of the other packages to ease codevelopment of these

[noblock]

[GunnarFarneback]

[noblock]
My comment does not relate to development but what is distributed by the package servers when a user adds SpeedyWeather from the General Registry and the other packages have also been registered. This will bring in

SpeedyWeather/
├── src
├── test
├── LowerTriangularArrays
├── RingGrids
├── SpeedyInternals
└── SpeedyTransforms

but the directories of the other packages just sit there and are unused. (Those packages are of course also installed since they are dependencies, but elsewhere on disk.)

If the repo structure instead is

repo
├── LowerTriangularArrays
├── RingGrids
├── SpeedyInternals
├── SpeedyTransforms
└── SpeedyWeather

the package server will just distribute

SpeedyWeather/
├── src
└── test

in the SpeedyWeather package.

at the same time have SpeedyWeather main always use main of the other packages to ease codevelopment of these

You can still do that with a sources section in SpeedyWeather/Project.toml, only it has to point to ../RingGrids instead of RingGrids etc.

But arguably better is to have a (non-package) environment at the top of the repository with sources pointing to all your packages and use that for development.

[milankl]

[nonblock] Great, thanks for the explanation I was looking for this in some documentation but thanks for clarifying it so nicely!

[milankl]

superceded by #138125 following the suggested name change here