-
Notifications
You must be signed in to change notification settings - Fork 462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New package: FortranNamelistParser v0.1.0 #117266
base: master
Are you sure you want to change the base?
New package: FortranNamelistParser v0.1.0 #117266
Conversation
JuliaRegistrator
commented
Oct 14, 2024
•
edited
Loading
edited
- Registering package: FortranNamelistParser
- Repository: https://github.com/anchal-physics/FortranNamelistParser.jl
- Created by: @anchal-physics
- Version: v0.1.0
- Commit: 11bfa8fef52e7d9b310f4beb6717820e9cf5fc5d
- Reviewed by: @anchal-physics
- Reference: anchal-physics/FortranNamelistParser.jl@11bfa8f#commitcomment-147970367
- Description: A pure Julia implementation of Python f90nml package.
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 registrationPlease 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 registrationIf 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 Tip: You can edit blocking comments to add |
Just to clarify: This is re-registering #117175, but with a new UUID? Cf. https://discourse.julialang.org/t/remove-package-from-general-registry/71668/5 I'm still pretty confused between this and #117210 Also, this being a fork of https://github.com/singularitti/Fortran90Namelists.jl and the comment at #116638 (comment) Usually, we don't allow for the registration of forks. The statement in the README
seems very strange. How is that compatible with #116638 (comment)? I don't understand why this package exists under multiple names. Can you clarify the relationship of all these packages and put that explanation in the README or documentation as well? [noblock] |
@goerz I was unaware of the existence of #117210 . We can test it with our packages to see if it takes care of all that we need. If that's the case, there is no need for this PR (FortranNamelistParser.jl). If #117210 does not support our project repos, we would like to get this PR merged so that we can register other packages that rely on this functionality. The situation is this:
Now, we wanted to publish our packages and register with Julia but @singularitti wants to work more on their package before registering it with Julia (probably because they have a much larger application scope in mind). So with permission form @singularitti we are publishing a fork of his latest repo with the additional two functions. I added the strange statement in README because I did not want anyone to misconstrue this as me stealing @singularitti's contribution. @singularitti is the major contributor of all the code in the package. But since it is under MIT license, we wanted to register it ourselves so that we can register our other packages. So, I'll definitely put this relationship between packages in README and docs soon. I'll also see if #117210 is good enough for our purposes, in which case, we'll abandon this package. [noblock] |
Are you sure that you and @singularitti (and @seamsay) can't agree on having everything in one package? From a community perspective, it's not ideal to have multiple variants of more or less the same package, all with basically interchangeable names. If your version of the package is not identical to the original one from @singularitti, you'd definitely have to rephrase that paragraph in the README and documentation,
In any case, it seems to me that parsing Fortran namelists is a pretty limited problem domain, and a single well-maintained and documented package should probably be enough to cover it. [noblock] |
Hi @goerz @anchal-physics, thanks for the heads-up! I’ve been pretty busy lately and wasn’t aware that there’s a new package [noblock] |
Hi @goerz @singularitti , I tried using FortranNamelist for my purpose, but it seems to have been written for a different usecase. It emulates reading and writing of namelist as is done in Fortran, while we simply want to parse Fortran namelists written or read by other Fortran based softwares and use the information, ideally as a dictionary. So I don't think it meets our needs. Again, I would emphasize that I simply want a working dependency registered here as soon as possible so that we can release our other packages. We'll be more than happy to change dependency to a better working and up to date solution when it comes up in the registry next. However, @goerz if this seems unreasonable from the community point of view, which I understand, then I'll try to trim our packages so that we don't use FortranNamelistParser anymore which reduce our functionality only slightly but we would definitely require it in future to expand further as we are reading Fortran based simulation outputs. Let me know what you think is the best solution here. [noblock] |
UUID: bd7787d8-51bb-4c23-a6f0-6dba939e3d23 Repo: https://github.com/anchal-physics/FortranNamelistParser.jl.git Tree: 80c646bc8b19c30c9ed6c5e050c06158b785c860 Registrator tree SHA: 17aec322677d9b81cdd6b9b9236b09a3f1374c6a
a47e29a
to
9504e40
Compare
Maybe there's room for two packages, I don't know. Maybe I'll have to solicit some opinions on this. If there's some consensus in the community that having all three of these packages registered is fine, I certainly won't stand in the way. If this registration of [noblock] |
Hi @anchal-physics, I don't have time to look over your package or this PR properly until the weekend but specifically regarding
Would the |
[noblock] Just for the record: I think my ideal outcome would be if it's somehow possible for @Sean1708 to implement whatever features @anchal-physics is missing in order to use |
Hi guys, sorry for the late reply. I was pretty busy recently. I'm fine with whatever decisions you made in the end. I'd love to see Sean's code registered. If not, I could contribute to Anchal's repo later. |