Modularisation of pyg4ometry and refactoring

[stewartboogert]

Split pyg4ometry into multiple packages will make maintenance easier. Different users have different requirements of pyg4ometry, separation will allow users to avoid heavy dependencies. Potential divisions (or packages) are

• Core Geant4 (geant4, gdml) - pycgal
• Visualisation (visualisation) - VTK
• FLUKA (fluka) - pycgal
• MCNP (mcnp) - none
• Convert (convert) - fluka, mcnp, usd, root
• USD (usd) - openusd
• CAD (pyoce) - open cascade

Each new module can be reviewed for modern python usage

• Logging
• Update to f-strings terminal output
• Type hints/checking
• Context management (with)

Rather than copy pasting code, it would be better to create an empty package with all style checks enabled and slowly populating it.

Potential new packages

• pyg4ometry-cgal
• pyg4ometry-core (geant4, gdml, transforms, exceptions, compare, config, cli)
• pyg4ometry-visualisation (vtk, usd etc)
• pyg4ometry-cad (pyoce)
• pyg4ometry-convert (fluka, mcnp)
• pyg4ometry-extra (root, features, bdsim, misc, analysis, montecarlo)

The main issue is where to locate pycgal. This is baked into geant4.solids and it could be factored out up front.

[gipert]

I would start already thinking about names (eventually separately for package and module). Happy to hear @ManuelHu's ideas/comments about this.

[ManuelHu]

would something like this help? https://packaging.python.org/en/latest/guides/packaging-namespace-packages/

[gipert]

I'm not sure, I would just create multiple packages.

[lnevay]

Would you make a meta package for all? For my usage I need 5 of those proposed packages always.

[gipert]

Would you make a meta package for all? For my usage I need 5 of those proposed packages always.

I think pyg4ometry should stay the same and just link all the packages, no change of functionality. But it's important to start factoring out some parts so that some downstream users (i.e. many LEGEND packages) can depend on lighter packages.

[ManuelHu]

Starting with

• pyg4ometry-cgal
• pyg4ometry-core (geant4, gdml, transforms, exceptions, compare, config, cli)

seems quite obvious for me, as it would also give us the largest return. However, to we really want to have the cli there? I guess not, as the CLI mostly deals with exporting and loading of all supported formats, which we cannot provide in -core.

edit: after the refactoring, the main package would depend on pyg4ometry-core and re-export the things from -core?

[stewartboogert]

Would you make a meta package for all? For my usage I need 5 of those proposed packages always.

I definitely think there will be a meta package for our typical usage. Which is for a lot of the sub-modules/packages.