Enable um2nc entrypoint without install

[truth-quark]

To run um2nc, amami & its dependencies need to be installed into an environment. This is fiddly for development as um2nc changes either have to be installed each time, or modifications made to the environment (a hacky approach). The key problem is there's no __main__ entry point in the root amami.py (this is generated during the install with PBR).

• [ ] Add __main__ entry point to amami.py
• [ ] Ensure um2nc can be called from cmd line without needing to install amami into the env

[atteggiani]

@truth-quark I do not see having to install amami in the environment as fiddly for development. To run um2nc you would still need a Python environent with all the needed dependencies (iris, mule to name some) installed. Installing or not installing another dependency ( in this case amami) does not really make any difference.

[truth-quark]

@truth-quark I do not see having to install amami in the environment as fiddly for development.

The issue is to do with changes to particular files, e.g. um2nc.py. Any changed files have to be reinstalled into the environment for testing, potentially after each file change during dev/test cycles. This is fiddly & can be forgotten. In other projects there's an environment for external dependencies, whilst tests/cmd line scripts are run on local dev project files. This allows immediate testing/running against any code changes.

[atteggiani]

No, what you wrote can be managed by installing the dependency as editable by using the -e flag in the pip install comand.

From pip install documentation:

-e , --editable <path/url> Install a project in editable mode (i.e. setuptools “develop mode”) from a local project path or a VCS url.

So, for development, you can install amami in your Python environment with:

pip install -e .

and any change you make to any file in the amami package will be automatically reflected in the environment without the need to reinstall anything.

[truth-quark]

Ok, there's a feature I've not seen before (preferring to keep the env & dev project deps "separate").

[atteggiani]

I will close this issue then.

[truth-quark]

I still need to add/test adding a __main__ block into the main amami module to signify it's a standard entry point. The current state is somewhat confusing as it's relying on a generated module to create a __main__. I'd like to make it clearer.

[atteggiani]

But I think adding the entry point in the console_scripts of setup.py is standard practice and makes it very clean.

We just need to make it clear in the README how to install the package (for eventual people who want to install a local version). But most of the users will use it as installed in a pre-configured environment on Gadi, so they don't have to worry about installation.

[truth-quark]

But I think adding the entry point in the console_scripts of setup.py is standard practice and makes it very clean.

From a developer viewpoint, I'm looking for if __name__ == "__main__:" as an indicator of code running as a script. Without it, I had to find another explanation, in this case the main is created implicitly during install. This is less obvious to me than including explicit Python code for running as a script.

We just need to make it clear in the README how to install the package (for eventual people who want to install a local version). But most of the users will use it as installed in a pre-configured environment on Gadi, so they don't have to worry about installation.

I'd still like to treat the project from at least 3 perspectives: developers, sysadmins & anyone using it pre-installed. Dev focused setup docs are needed for the long term & guard against knowledge loss from staff churn. Couldn't other devs join the project and add more tools?

[atteggiani]

From a developer viewpoint, I'm looking for if name == "main:" as an indicator of code running as a script. Without it, I had to find another explanation, in this case the main is created implicitly during install. This is less obvious to me than including explicit Python code for running as a script.

Yes I can understand, in fact it should be specified in the README, so it is clear for any future developer (and user).

I'd still like to treat the project from at least 3 perspectives: developers, sysadmins & anyone using it pre-installed. Dev focused setup docs are needed for the long term & guard against knowledge loss from staff churn. Couldn't other devs join the project and add more tools?

I perfectly agree, but none of these perspective require a separate entry point to be created.

• Developers They should clone the repo, create a Python environment, and install an "editable" version of amami in it with pip install -e .. Then its functionality will be available as a CLI and they can test it with amami -V.
• Users on Gadi They simply need to load the pre-configured environment (something like module load environment-with-amami). Then its functionality will be available as a CLI and they can test it with amami -V.
• Users that want to install it themselves They simply need to use pip install amami (or conda install amami if we release it with conda) in their Python environment where they want to install it. Then its functionality will be available as a CLI and they can test it with amami -V.

These steps should be specified in the README, but no different entry point needs to be created.