New package: FNCFunctions v1.0.0

[JuliaRegistrator]

• Registering package: FNCFunctions
• Repository: https://github.com/fncbook/FNCFunctions.jl
• Created by: @tobydriscoll
• Version: v1.0.0
• Commit: 0806d384614cfe717f683a3bea0adc3f7551660d
• Reviewed by: @tobydriscoll
• Reference: fncbook/FNCFunctions.jl@0806d38#commitcomment-150962510
• Release notes:

These have been split from the original FundamentalsNumericalComputation.jl package in order to remove the excessive dependencies. They are also improved in appearance and updated to avoid some deprecation warnings.

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

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]

Thank you for submitting your package! Please make sure the package is fully documented before registering. Especially for an initial version v1.0, you're indicating that the package has a stable API. That has some implications for the expectations for the package:

• Must define the stable API. That generally means complete documentation.
• Must have tests with reasonable coverage (on the order of 80%). Otherwise, there's no way to know if the package actually implements its API correctly, and no basis for figuring out whether a pull request is "breaking" or not, going forward.
• Should somewhat reasonably fill the described scope of the package. No major gaps in functionality.

For an initial version v0.1, the bar would be lower:

• Must have a name that is appropriate for the scope of the package
• Must have some non-trivial functionality (no "placeholder" packages)
• Must have a README that explains the purpose of the package and gives a basic usage example.

[noblock]

[aplavin]

If these are the official rules of General @goerz, please consider adding them to the README or to some other place in the docs – before asking to follow that from all users. Otherwise, the first part (specific to v1.0) sounds like a subjective set of preferences, not a registration requirement.

Meanwhile, I of course agree with the remainder: name, non-trivialness, docs are the actual rules, already mentioned in the docs.

[noblock]

[goerz]

@aplavin They are not official rules, but I feel perfectly fine with leaving a blocking comment on registrations that do not meet what I consider reasonable standards. Any member of the community is free to do the same.

None of it is a registration requirement. Any registry maintainer can override blocking comments. We really have almost no absolute, hard requirements for registration. Only guidelines, and I believe that all of my points are in the spirit of those guidelines.

[noblock]

[tobydriscoll]

I think I had not previously set up the repo to have its Pages site active. The dev version of the docs is up now, and I have updated the README to point to it and give some guidance. This is an unusual package. It's purely meant for pedagogy, not scientific work, as stated now in the README. The book is 95% complete and also found via the README. It serves as the real documentation, which is why the formal docs are pretty spartan. I hope that makes sense. I'm not familiar with the code coverage tools, but all the functions are tested and not too complex. Also, the textbook has 100+ demos that thoroughly exercise them. It's been out for a few years now, too. Thanks, Toby

…

--- Tobin Driscoll Unidel Chaired Professor of Mathematical Sciences Director, Master of Science program in Data Science University of Delaware, Newark, DE 19716

On Mon, Jan 6, 2025 at 4:31 PM Michael Goerz ***@***.***> wrote: @aplavin <https://github.com/aplavin> They are not official rules, but I feel perfectly fine with leaving a blocking comment on registrations that do not meet what I consider reasonable standards. Any member of the community is free to do the same. None of it is a registration *requirement*. Any registry maintainer can override blocking comments. We really have almost no absolute, hard requirements for registration. Only guidelines, and I believe that all of my points are in the spirit of those guidelines. — Reply to this email directly, view it on GitHub <#122478 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3JNLVWHEEYUWLVSDHEUFL2JLY2VAVCNFSM6AAAAABUV3TK42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZTHE3DCNZTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aplavin]

@goerz it would be counterproductive if everyone wrote blocking comments with their personal preferences on how Julia packages are supposed to look. Say, I prefer package names consisting of no more than two words, and I leave a comment in every new registration that has 3 or more. IMO that is an unreasonable thing to do, and same with your 1.0 "rules". If you think they are actual widely-applicable recommendations, add them to General / AutoMerge guidelines!

Following others' advice, I was considering starting all my new packages at 1.0 so that to have an extra version number just in case. The version number doesn't say anything universal really, aside from having 2 vs 3 numbers to play with. At least now I know that you intend to block all 1.0 registrations, and will just do 2.0.0 if I decide I need 3 numbers :)

To @tobydriscoll: assuming you fix all other issues and the name is ok, you can either ask at Slack#pkg-registration to merge this, or register 0.1 and immediately bump to 1.0 after registration.

[noblock]

[goerz]

[noblock]

@tobydriscoll Thanks for the updates and the explanation, that looks totally fine to me! I'll be happy to unblock my comment.

I'm not familiar with the code coverage tools

In general, "code coverage" is just keeping track of which lines get run during the tests (via a command line flag to Julia), and uploading it to Codecov (what most Julia packages use). The main reason to aim for a reasonably high percentage of covered lines in a v1.0 is that it provides a way to track if future changes are breaking. Without tests, it's very easy to accidentally introduce a breaking change inadvertently.

@aplavin

it would be counterproductive if everyone wrote blocking comments with their personal preferences on how Julia packages are supposed to look.

That depends on how unusual their personal preferences are. Insisting that v1.0 packages must define their API doesn't seem like something that should be overly controversial. As for the specific details of my "requirements", you should see those as a "working definition" that is absolutely open to negotiation. Which is also why I would be reluctant to nail that down in any official guidelines.

Following others' advice, I was considering starting all my new packages at 1.0 so that to have an extra version number just in case.

As far as your existing packages go, as far as I've seen, they have documentation and make SemVer guarantees about their API, so I think you should register a v1.0. For new registrations, I don't necessarily object to starting with v1.0, as long as they fully document their API.

The version number doesn't say anything universal really, aside from having 2 vs 3 numbers to play with.

I know you believe that, but it's just not true (if you're following the SemVer spec). But it's also beside the point: You like to treat v0.x versions as stable, which I don't think is a great idea, but it's not a violation of SemVer, and it's not that big of a deal. But in any case, that doesn't affect the semantics of a v1.0 version, which SemVer defines as the version that specifies the stable API. I'm just asking that packages tagged as v1.0 actually do that.

At least now I know that you intend to block all 1.0 registrations

I have no such intention!

will just do 2.0.0 if I decide I need 3 numbers

That's just being silly, and, of course, v2.0 has the same requirements as v1.0

assuming you fix all other issues and the name is ok, you can either ask at Slack#pkg-registration to merge this,

Or, just engage with my comment, assuming good faith. These "requirements" are in no way hard rules. I'm more than happy to unblock after reaching common ground, as happened here. Asking on Slack from someone to override my (or anyone's) objections would only be necessary if the discussion does not reach a consensus.

or register 0.1 and immediately bump to 1.0 after registration.

Technically, yes, but that doesn't change the semantics of a v1.0 release. It's a bit unfortunate that there's no waiting period for v1.0 releases (something I might advocate for in the future). But yeah, if you're hell-bent on going out of your way to avoid defining an API for your v1.0 packages, or otherwise ignore the requirements of SemVer, that's ultimately between you and your users. There's only so much I can do to push people in the right direction.

[tobydriscoll]

@goerz I know what code coverage is in general. I just don't know how to feel about a badge that says 65% coverage versus one that says 85%.

For this application, it's not worth the hassle to me, so I am downgrading to v0.1.0.

[goerz]

For this application, it's not worth the hassle to me, so I am downgrading to v0.1.0.

That wasn't really a strict requirement. If you are confident that you'll be able to know whether any future PR on your package will be breaking or not, I'm totally fine if you want to tag the initial version as v0.1.0.

[noblock]

[goerz]

Closing in favor of #122529

You still have to fix the Julia compat issue, though