New package: UFFio v0.1.0

[JuliaRegistrator]

• Registering package: UFFio
• Repository: https://github.com/maucejo/UFFio.jl
• Created by: @maucejo
• Version: v0.1.0
• Commit: dc570cae8a37028da481e7fdf9a65972c34b0865
• Reviewed by: @maucejo
• Reference: maucejo/UFFFiles.jl@dc570ca#commitcomment-169371082
• Release notes:

This new package aims at providing tools for reading Universal File Format files.
It currently supports only reading functionalities for datasets: 15, 18, 55, 58, 82, 151, 164, 2411, 2412, 2414.

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

[nilshg]

[noblock] If you just did this because UFFReader didn't pass the name similarity check that's not necessary - name similarity is just an automated check against typo squatting, and can easily be overriden. If you prefer UFFReader just ask for name similarity to be overriden in the #pkh-registration slack channel.

[maucejo]

[noblock] If you just did this because UFFReader didn't pass the name similarity check that's not necessary - name similarity is just an automated check against typo squatting, and can easily be overriden. If you prefer UFFReader just ask for name similarity to be overriden in the #pkh-registration slack channel.

Thank you sincerely. This naming issue made me crazy. After all these iterations, I find UFFio.jl is fine. I keep this last name.

[goerz]

Actually, I would consider UFFio to be quite problematic, as it violates CamelCase. The acronym IO should still be capitalized, since it's an acronym. UFFIO might be okay in principle (although not very readable), but it would require approval and merging from a full registry maintainer, which probably isn't worth the trouble.

I would strongly recommend going back to UFFReader in #141607. Or, of course, UniversalFileFormat, as you had planned to in #141602 (comment). Or still UFFFiles if you want something shorter and you may implement writing in the future. Note that "short" isn't something package names should strive for when it sacrifices clarity. As the guidelines say, "Err on the side of clarity, even if clarity seems long-winded to you." The name UFFReader is definitely fine. It would match the pattern that we often encourage for other file format packages, of <EXT>(Format|Files|Writer|Reader). Because it's a pattern we encourage, that often causes the bot to flag a name similarity issue, but those name similarities are false positives, and I can easily override them

This naming issue made me crazy.

I understand these things can be frustrating, but remember that registrations are permanent. That's well worth the effort of making sure the package name is suitable and matches the guidelines. Don't get too caught up and sleep on it for a night. Changing the name back will only take a few more minutes of your time

[maucejo]

Actually, I would consider UFFio to be quite problematic, as it violates CamelCase. The acronym IO should still be capitalized, since it's an acronym. UFFIO might be okay in principle (although not very readable), but it would require approval and merging from a full registry maintainer, which probably isn't worth the trouble.

I would strongly recommend going back to UFFReader in #141607. Or, of course, UniversalFileFormat, as you had planned to in #141602 (comment). Or still UFFFiles if you want something shorter and you may implement writing in the future. Note that "short" isn't something package names should strive for when it sacrifices clarity. As the guidelines say, "Err on the side of clarity, even if clarity seems long-winded to you." The name UFFReader is definitely fine. It would match the pattern that we often encourage for other file format packages, of <EXT>(Format|Files|Writer|Reader). Because it's a pattern we encourage, that often causes the bot to flag a name similarity issue, but those name similarities are false positives, and I can easily override them

This naming issue made me crazy.

I understand these things can be frustrating, but remember that registrations are permanent. That's well worth the effort of making sure the package name is suitable and matches the guidelines. Don't get too caught up and sleep on it for a night. Changing the name back will only take a few more minutes of your time

Don't worry, it is fine. I will revert things to UFFReader, even if writing fuctions will be available in a near future. The only question is "How to submit the PR with UFFReader and avoid the false positive ?"

Best regards

[goerz]

I will revert things to UFFReader, even if writing fuctions will be available in a near future.

Umm... sorry, but no. If the package will implement writing, UFFReader would be a misrepresentation. We require that package names accurately reflect the functionality of the package.

The only question is "How to submit the PR with UFFReader and avoid the false positive ?"

That part is easy. If you retrigger the registration after you rename, it will just update the existing #141607, for which I've already applied the override.

In general, for any registration, I will more or less automatically override any name similarity that the bot gets wrong (which is 95% of them)

[goerz]

Given that UFFio is presumably because "This will also implement writing", not "I got too frustrated with the process", this is something where I'd "let the author have the last word". I don't think it's ideal compared to the alternatives (remember we're not aiming for "short"), but it's also not something that's so egregious that it can't be merged.

In that case, there's be nothing else to do, apart from you confirming that's the way you want to go. Sleep on it for a night, though. As I said, registrations are permanent, so you'd want to put your best foot forward as much as possible.

[maucejo]

Given that UFFio is presumably because "This will also implement writing", not "I got too frustrated with the process", this is something where I'd "let the author have the last word". I don't think it's ideal compared to the alternatives (remember we're not aiming for "short"), but it's also not something that's so egregious that it can't be merged.

In that case, there's be nothing else to do, apart from you confirming that's the way you want to go. Sleep on it for a night, though. As I said, registrations are permanent, so you'd want to put your best foot forward as much as possible.

Ideally, I'd like to name the package UFF.jl, just like CSV.jl or JSON.jl. Is it possible ?

[goerz]

Ultimately, “possible” comes down to “are you going to find a full registry maintainer willing to merge it”. But realistically, no. There seems to be a pretty strong consensus that short acronyms or file extensions are a no-go, and that these should be combined with an appropriate and descriptive suffix or prefix

[maucejo]

Ultimately, “possible” comes down to “are you going to find a full registry maintainer willing to merge it”. But realistically, no. There seems to be a pretty strong consensus that short acronyms or file extensions are a no-go, and that these should be combined with an appropriate and descriptive suffix or prefix

So, if I propose UFFIO, is it acceptable ?

I really thank you for your patience and your help

[goerz]

UFFIO has the benefit of being proper CamelCase, but two significant drawbacks: it’s not particularly readable, and it also needs a full registry maintainer to merge (but you could probably find one, if you prefer that route). Personally (after some reflection) I’m not even sure if I’d prefer UFFIO or UFFio. Both have their benefits. I think the “use proper CsmelCase” might be a particular pet peeve of mine; others might say “UFFio is totally fine”. You could ask on Slack for more community opinions. I’m warming up to it a little.

Still, what’s wrong with UFFFiles?

[goerz]

So, in short: I’ll unblock UFFio if that’s what you want, but I’d be happier with UFFFiles or UniversalFileFormat. But this is all in the realm of “author should have the last word”. So it’s up to you

[maucejo]

So, in short: I’ll unblock UFFio if that’s what you want, but I’d be happier with UFFFiles or UniversalFileFormat. But this is all in the realm of “author should have the last word”. So it’s up to you

I was initially reluctant to name the package UFFFiles (because of the three Fs), but I think it is a good compromise. So, I will name the package UFFFiles.

[goerz]

Closing in favor of #141659