search

metno / snap

Severe Nuclear Accident Programme
GNU General Public License v3.0
23 stars 6 forks source link

Use declarative setup for SnapPy #101

Open magnusuMET opened 2 years ago

magnusuMET commented 2 years ago

This does bring big changes, but helps reduce confusion in which package version one is running. It can be quite confusing when the import pulls in the installed package instead of the edited one. I find it more obvious to do this the pythonic way with pip install --editable. All places where scripts were being run directly has been changed to run from PATH afaik.

Is the distinction between bsnap and snap-py that obvious now? We have 8 programs under snap-py which does not depend on QT, in fact I have placed snapPy dependencies under extras. I think of bsnap as binary snap, a driver used by snapPy, and snapPy as all utilities supporting the model.

heikoklein commented 2 years ago

It is true that the scripts under utils/SnapPy consists for two reasons: Graphical usage "snapPy", "snapCombineInverse", (invoked best from graphical, never used it non-graphical, but might be possible, maybe should be moved to bsnap?)

Operational usage: "snap4rimsterm", "snapNc2grib.py", "snapRunnerNpps", "snapRunnerNpp", "eemepModelRunner", "snapRemoteRunner.py",

So the operational ones could be removed from the debian snap-py package.

But not enough reason to put them all into another directory.

heikoklein commented 1 year ago

Rather than just moving to declarative setup.cfg, this PR requires many changes to the interna of the package. It hasn't been worked on in several month. And for a change to a declarative setup. PEP518/pyproject.toml (from 2016) should be used rather than setup.cfg. I suggest closing this PR and if still of interest, starting a new PR just replacing setup.py with pyproject.toml (for compatibility, please keep a boilerplate setup.py)

magnusuMET commented 1 year ago

The move to setup.cfg would greatly simplify conversion to pyproject.toml when python3.6 is phased out (pyproject.toml is not fully supported under 3.6)