New package: JLCL v0.1.0

[JuliaRegistrator]

• Registering package: JLCL
• Repository: https://github.com/marcoxa/JLCL.jl
• Created by: @marcoxa
• Version: v0.1.0
• Commit: afecfb2faac0e240a8b2b6fbe8aab9d4f3694ed6
• Reviewed by: @marcoxa
• Reference: marcoxa/JLCL.jl@afecfb2#commitcomment-141187416
• Description: Some utilities and macros to help Julia programming.

[github-actions]

Your new package pull request does not meet the guidelines for auto-merging. Please make sure that you have read the General registry README and the AutoMerge guidelines. The following guidelines were not met:

• Name does not meet all of the following: starts with an upper-case letter, ASCII alphanumerics only, not all letters are upper-case.
• Name is not at least 5 characters long
• No licenses detected in the package's top-level folder. An OSI-approved license is required.
• Package name similar to 6 existing packages.
  1. Similar to JLSO. Damerau-Levenshtein distance 2 is at or below cutoff of 2. Normalized visual distance 2.44 is at or below cutoff of 2.50.
  2. Similar to JLD2. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  3. Similar to JLD. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  4. Similar to JACC. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  5. Similar to NCCL. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  6. Similar to LSL. Damerau-Levenshtein distance 2 is at or below cutoff of 2.

Note that the guidelines are only required for the pull request to be merged automatically. However, it is strongly recommended to follow them, since otherwise the pull request needs to be manually reviewed and merged by a human.

After you have fixed the AutoMerge issues, simply retrigger Registrator, which will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless of course the AutoMerge issue is that you skipped a version number, in which case you should change the version number).

If you do not want to fix the AutoMerge issues, please post a comment explaining why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the Julia Slack to ask for help. Include a link to this pull request.

Since you are registering a new package, please make sure that you have also read the package naming guidelines: https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines

---

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. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[goerz]

Unfortunately, I don't think this package is suitable for registration.

• As it stands, the name is not descriptive of the package. Something like InModule.jl might work

• "Some utilities and macros to help Julia programming" is indicative of a personal package, which are not accepted in the General registry

• The package does not contain sufficient functionality to be described as "things missing from a Common Lisp perspective". With a well-defined scope, there might be suitable name for such a package, but JLCL is not okay. It's too short, non-descriptive (jargony acronym), and has the JL prefix, all of which are disallowed.

• The license is not suitable for registration. The note in the README

  I ask you to consider plain old "cooperation" by asking me to become a developer.

  is very unusual. Do you mean to ask people to submit pull requests to your package?

[marcoxa]

Hi Michael I understand and you are right about the scope (very minimal FTTB) of the package. For me it was, above, all an exercise in following the process. I am an old (very old) priest of the parenthetical cult and I am planning to build some more extensions to make me (and other old geezers) more at home in Julia; plus we are a bunch of lazy cats, but I digress. I will keep the package "personal" for the time being and rename it if I will try to resubmit. Just two things: the package does have a BSD license (I did my postdoc in Berkeley; I cannot use an MIT license!) and the "unusual" note in the README is there in all my libraries, but I can move it to a NOTES.md file. Thanks All the best Marco

…

On Sun, Apr 21, 2024 at 4:09 AM Michael Goerz ***@***.***> wrote: Unfortunately, I don't think this package is suitable for registration. - As it stands, the name is not descriptive of the package. Something like InModule.jl might work - "Some utilities and macros to help Julia programming" is indicative of a personal package, which are not accepted in the General registry <https://github.com/JuliaRegistries/General?tab=readme-ov-file#should-i-register-my-package-now> - The package does not contain sufficient functionality to be described as "things missing from a Common Lisp perspective". With a well-defined scope, there might be suitable name for such a package, but JLCL is not okay. It's too short, non-descriptive (jargony acronym), and has the JL prefix, all of which are disallowed. - The license is not suitable for registration. The note in the README I ask you to consider plain old "cooperation" by asking me to become a developer. is very unusual. Do you mean to ask people to submit pull requests to your package? — Reply to this email directly, view it on GitHub <#105297 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5SWXZJZVOCFXWBA4NCBTY6MNVFAVCNFSM6AAAAABGQWRJM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXHA2TONJYGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Marco Antoniotti Somewhere over the Rainbow

[goerz]

I am an old (very old) priest of the parenthetical cult and I am planning
to build some more extensions to make me (and other old geezers) more at
home in Julia; plus we are a bunch of lazy cats, but I digress.

That's totally fine. What would make such a package uncontroversial would be to have a sort of an essay in the README/documentation that identifies common concepts for package writing in CL and compares them to Julia. That would give the package a scope of "macros/functions to bringer over the CL mindset of package development to Julia". As long as the package has substantial functionality to fill that scope (more than a single macro), it would be fine to register under an appropriate general name.

the package does have a BSD license

The BSD license if fine, of course, but GitHub (and the JuliaRegistrator bot) do not recognize the LICENSE file as BSD. You have to use the standard BSD LICENSE file (as GitHub would generate it for you), without modifications. There's no need to have two different license files. Use either LICENSE or COPYING.

the "unusual" note in the README is there in all my libraries

You can put in whatever you want (and you don't have to move it from the README to some other file). It's not a blocker for registration. But I'm not sure what development model you have in mind. Usually, people would contribute to your package with pull requests. Real forks — where people fork the project to take it in a different direction, as opposed to the "fork" one has to do on GitHub to prepare a pull requests – are strongly discouraged, at least in the Julia community. When you register a package, you become responsible for maintaining it. We do not generally accept forks of existing packages for registration (at least not if they have substantially diverged and have a new name).

There might be packages that prefer "fork to adapt to your own needs" (I have one of those myself, in Python), but such a package would be a personal package by definition and not suitable for registration.

There are almost no circumstances I can think of where I would add an original maintainer to a fork as a contributor. Unless you are talking about the "Allow edits by maintainer" checkmark on a pull request. So yeah, you can put a note like that in your README, but it will most likely just confuse people and be ignored.

Anyway, I'll close here for now, but you are definitely welcome to resubmit with a different name, and/or once the package has grown a bit more.

[goerz]

In the meantime (or in general, for "personal packages"), I would recommend using a LocalRegistry