New package: FortranNamelistParser v0.1.0

[JuliaRegistrator]

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

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

[goerz]

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

This repository is forked from original repo from @singularitti. @singularitti is the major author of this package and the owner and mainter of this repository @anchal-physics is only taking care of julia registration and minimal maintainence.

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]

[anchal-physics]

@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:

• @singularitti started the project https://github.com/singularitti/Fortran90Namelists.jl
• We have been working on our packages in private repos earlier and we needed the base functionality of https://github.com/singularitti/Fortran90Namelists.jl and 2 additional functions, so this repo was forked in our org and we added the two functions.
• Meanwhile, @singularitti updated their repo bit more and made it better.

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]

[goerz]

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,

This repository is forked from original repo from @singularitti. @singularitti is the major author of this package and the owner and mainter of this repository @anchal-physics is only taking care of julia registration and minimal maintainence.

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]

[singularitti]

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 FortranNamelists.jl. After a quick review, it seems that FortranNamelists.jl is quite different from my design and has its own merits. @anchal-physics, could you test whether it meets your needs? If so, we could potentially collaborate to make this package the state-of-the-art Fortran namelist parser.

[noblock]

[anchal-physics]

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]

[goerz]

Maybe there's room for two packages, FortranNamelist as a reader and writer, and FortranNamelistParser here as a second approach. But IMO, I don't think there's then also room for Fortran90Namelists as a fork/variant for FortranNamelistParser. If we're merging FortranNameListParser now, I would be fairly opposed to having a registration of Fortran90Namelists at some later point in time. Instead, @singularitti would have to contribute any further development to the FortranNameListParser repository – which would probably be best anyway. Why do you want to keep two separate forks of the same project under active development? I can't imagine that the plans for the two forks are so divergent that these future developments would be incompatible.

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 FortranNamelistParser is only there as a dependency for the packages in a specific org, it might also be possible to just have the code in some Base/Core package of that org. Something that's a dependency of all the other packages, without specifically being about Fortran namelist parsing. Or, use a package name that makes it really clear that this package is specific to the context of a specific org, like TorreyPinesFortranNamelistParser. For a pure dependency that's not user-facing, a super long package name like that isn't really a problem, and it would make it clear to people that this package isn't intended for public use.

[noblock]

[Sean1708]

Hi @anchal-physics, I don't have time to look over your package or this PR properly until the weekend but specifically regarding

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.

Would the Namelist type as documented here not fit your use case? And if not, do you have an idea of what would need to change for you to be able to use it?

[goerz]

[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 FortranNamelists as the dependency for all their packages (or for @anchal-physics to contribute these features to FortranNamelists). Then, we can just move ahead with the registration of FortranNamelists and FortranNamelists` would be the "go to" package for Fortran namelists in Julia. Since you all have a stake in this package, maybe you can even all have co-maintainer status and commit access. It's always best if registered packages have a bus factor greater than one. But, whatever you guys decide is best.