Adapting the new entrypoints plugin mechanism and changing name of repo and package

[JosePizarro3]

@ndaelman-hu @Bernadette-Mohr @JFRudzinski @ladinesa

With your agreement, I'd like to change the name of the package to nomad_simulations_schema. I also need to fix imports to be absolute to the package path and not relative (i.e., change from .numerical_settings import KMesh to from nomad_simualtions_schema.numerical_settings import KMesh).

My idea was that:

• We call the general repo for parsers, nomad_simulations_parsers.
• Each individual parser is called nomad_<codename>_parser.
• The workflow plugin is called nomad_simulations_workflow_schema.

I think that would be enough to be clear. Still, the path in the NOMAD central repo should be dependencies/parsers/simulation/... or dependencies/schema/simulation/....

[ndaelman-hu]

With your agreement, I'd like to change the name of the package to nomad_simulations_schema

What's the time frame here? I don't care much for the naming, but I want a heads-up so all my open issues can first be merged. Then I can deal with reconfiguring.

Is this now the default naming convention then, i.e. can you assure that there won't be any other renamings down the road?

[JosePizarro3]

What's the time frame here? I don't care much for the naming, but I want a heads-up so all my open issues can first be merged. Then I can deal with reconfiguring.

It is a quick patch, so no problem on waiting, but the decision has to be made.

Is this now the default naming convention then, i.e. can you assure that there won't be any other renamings down the road?

The naming convention is the one we will decide.

[ladinesa]

okay for me.

[ndaelman-hu]

What's the time frame here? I don't care much for the naming, but I want a heads-up so all my open issues can first be merged. Then I can deal with reconfiguring.

It is a quick patch, so no problem on waiting, but the decision has to be made.

I'm finishing up 2 issues. Pls hold off till after merging those. This has no urgency.

Is this now the default naming convention then, i.e. can you assure that there won't be any other renamings down the road?

The naming convention is the one we will decide.

So, no, it's not guaranteed to last.

[JosePizarro3]

So, no, it's not guaranteed to last.

Why not? I think we can make this decision ourselves

[JosePizarro3]

After meeting with @ladinesa last week, I think we could keep this package to be nomad_simulations. For the other rules, will not have for now nomad_simulations_parsers, but we can still apply points 2. and 3.

Now, I think this package could become something bigger and better: thanks to the NOMAD sections and to our normalizations. I would like to hear what you think (@ndaelman-hu @JFRudzinski @Bernadette-Mohr @ladinesa). And also, I would like to know whether you have a more catchy name in mind (like pymatgen is for MaterialsProject 😄), or whether you would like to keep something like nomad_simulations.

[JFRudzinski]

ther you would like to keep something l

Totally agree!

I think the naming should depend on what we see the major usage of the project to be, external to NOMAD, and also the scope of applicability. In terms of the former, I think we need to brainstorm together to get a handle on this. I think probably there are lots of opportunities here depending on the domain. In terms of the latter, I see advantages and disadvantages to "branding ourselves" within a certain domain, e.g., materials simulations. We are already starting to branch out a little outside materials science, so we should consider this as well.

[JosePizarro3]

Making a decision on the repository and package names

Ok, closing a bit this: I think I would keep: nomad-simulations for the name of the repo, and nomad_simulations for the name of the package.

We can come back for a more catchy name in the future when this evolves, if we want to.

Adding the pluginas a nomad/dependencies submodule

Now, regarding deadlines, I will initially put 30.06 to change these names. As I said in the Discord, I will coordinate with @ladinesa to add this plugin as a dependency of nomad, so it will not be very complicated for us to set up the environment and develop the plugin.

Config parameters

As for the config parameters present in the old normalizers, we can safely move them to the new EntryPoints pydantic model, after asking @lauri-codes. I will also tackle this on this issue in one shot.