New package: AppleHealthParser v1.0.0

[JuliaRegistrator]

• Registering package: AppleHealthParser
• Repository: https://github.com/sumant-28/AppleHealthParser.jl
• Created by: @sumant-28
• Version: v1.0.0
• Commit: fe833a153c69d32c91d15384a913a4b5ef656e77
• Reviewed by: @sumant-28
• Reference: sumant-28/AppleHealthParser.jl@fe833a1#commitcomment-147469311

[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 are all met! ✅

Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

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

[carstenbauer]

Hi @sumant-28, this seems to be only your second attempt to register a package in the General registry. For this reason, and also because you asked on Slack about unit tests, let me leave a few comments about how you could (and probably should) improve your package to make it more suitable for registration in General:

1. Reusability: The idea behind registering packages is generally to share some reusable functionality that could be useful to (parts of) the Julia community (i.e. a certain function, for example). Scripts are generally not suitable for the General registry. Your package has a main function that isn't customizable at all - i.e. it take any arguments - and thus falls into the script category. For example, for your code to work, the input XML file must be named export.xml and must be located in the current directory. Typically, you would want to relax these constraints and also give main a more meaningful name, i.e. you might want to provide a clean function readxml(filename) as API instead.
2. Documentation: From reading your README, one has no clue how to use your package. You also have badges at the bottom that are supposed to point to documentation, but don't. At least a minimal "Usage" section would be nice.
3. Unit Tests: You don't have any. I recommend that you create a export.xml with "reasonable" dummy content, load it in your runtests.jl and test that you get the expected output.
4. Dependencies: Your are depending on Revise but don't seem to use it in your package.
5. Compat bounds: You are missing compatibility bounds for the versions of your package's dependencies. (This is why auto-merge failed, see above).

There is probably more to say but these are the most important points. Note that not all of them are mandatory for the registration to go through - we have few strict requirements for packages - but I strongly recommend that you try to implement these suggestions.

[noblock]

[carstenbauer]

Hi @sumat-28, did you see my comments above? Especially point 1) would be important to improve to make your package suitable for registration in General, at least in my opinion.

[goerz]

With some minor fixes, this should be totally fine to register… but it is definitely not yet at the level of maturity required for a 1.0 version. So I would ask to change the version number to 0.1 in addition to considering some of the other comments