New package: Tutorials v0.17.0

[JuliaRegistrator]

• Registering package: Tutorials
• Repository: https://github.com/gridap/Tutorials
• Created by: @JordiManyer
• Version: v0.17.0
• Commit: 8109809e082ac0f38d4d8108f74c44c77c68b9d6
• Reviewed by: @JordiManyer
• Reference: gridap/Tutorials@8109809#commitcomment-146524024
• Description: Start solving PDEs in Julia with Gridap.jl

[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 ❌

• Repo URL does not end with /name.jl.git, where name is the package name

• The following dependencies do not have a [compat] entry that is upper-bounded and only includes a finite number of breaking releases: CairoMakie, ChainRulesCore, DataFrames, DrWatson, FillArrays, GridapEmbedded, GridapMakie, IJulia, LineSearches, Literate, NLopt, NLsolve, Plots, Revise, Zygote

  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.

[goerz]

Clearly, this is too general of a name. I assume you were trying for something like GridapTutorials. Also, teaching materials or similar “personal” packages are generally not suitable for registration. If it’s not a dependency of another registered package, it doesn’t need to be registered.

[LilithHafner]

While I agree that Tutorials is too general a name for this, I disagree that only packages with dependents need to be registered. Specifically, packages that folks are likely to load directly (such as Chairmarks, Plots, Profile, PPTX) are worth registering even if they don't have registered dependents.

[goerz]

Yes, I agree with you.

That was badly phrased, and meant as a sufficient, but not a necessary condition. Maybe I should have emphasized the word "need": If it's a dependency of a registered package, it needs to be registered. But there are also plenty of end-user packages that are perfectly fine to be registered, and are very valuable to have as part of the ecosystem. At the same time, I would invite authors of some "standalone" packages to think about whether registration in General is necessary. I think teaching material is often in the category of packages that don't need to be in General, but can remain either unregistered or go in a LocalRegistry. That's by no means a "rule" of course: As always, we can see on a case-by-case basis whether some particular registration might be a problem.

[JordiManyer]

Sorry, this was my bad. This is a package we do not register, we only create tags. I just launched the bot out of habit. We did not mean to register it.