Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make mepo a module, address functions with module shorthands #273

Open
amdasilva opened this issue Apr 2, 2024 · 0 comments
Open

Make mepo a module, address functions with module shorthands #273

amdasilva opened this issue Apr 2, 2024 · 0 comments
Assignees

Comments

@amdasilva
Copy link

amdasilva commented Apr 2, 2024

@tclune @pchakraborty I realize that I am being a little picky here, but these are general suggestions for hepo.

  1. Make mepo a bona fide module. Under src/mepo include a proper __init__.py
  2. Better yet, rename src/mepo/main.py as__init__.py
  3. Because mepo now is a module, from within the module, use python3 style "." for including stuff from within the module. See GMAOpyobs/src/pyobs as an example. Do not have constructs such as:
    from mepo.state.exceptions import SuffixNotRecognizedError
  4. Unless you have large submodules, there is no need for excessive subdirectories under src/mepo. If you do need a directory for a submodule, make sure it has its own __init__.py. Otherwise, include the python sources under src/mepo. As a rule of thumb, there should not be a directory without a __init__.py
  5. Avoid explicitly importing functions from modules. Instead of Fortran like style (which I used to do)
    from numpy import pi, sin
    zero = sin(pi)
    do this
    import numpy as np
    zero = np.sin(np.pi)
    This is a basic maintenance device. Otherwise, you have to be editing the import line every time you need another function from numpy. Also, abbreviating packages with 2 letters ("np" for numpy) is an established convention.
@amdasilva amdasilva changed the title Make memo a module, address functions with module shorthands Make mepo a module, address functions with module shorthands Apr 2, 2024
mathomp4 pushed a commit that referenced this issue May 15, 2024
* Code reorganization to address #273

* Fixed issues with renaming config_file as registry

* Removed a print statement left in by mistake

* On our way to more robust testing

* Added nocolor option to 'git branch list'

* It's enough to chdir to the fixture dir at the beginning of a test

* Added 'mepo branch' tests

* Added tests for mepo tag, fetch, pull, pull-all

* multiprocessing library supports the context management protocol

* Added tests for mepo push, diff, whereis and reset

* component.py - using Python3's relative import

* Suppressing test outputs to terminal

* Turning off testing 'mepo reset' and checking why 'mepo diff' is failing

Maybe 'mepo reset' is causing issues with testing 'mepo tag create'

* For testing 'mepo diff', ignore the last line '---'

* Ignore the last line of both stdout and saved outputs

* Escaping the string message of 'git tag create'

* Create regular (non-annotated) tag instead

* Testing 'mepo reset' is back on - this was not the issue

* Code from src/mepo/command/command.py included in src/mepo/__main__.py

* Small edits

* Updated GEOSfvdycore version for testing

* Minor quote changes

* Using SimpleNamespace to construct arguments to mepo commands

* Multiprocessing lib supports context manager protocol

* Removed tests/input/args.py - using SimpleNamespace now

* Updated README and CHANGELOG

* Moved duplicate code to get GIT_EDITOR, in commit.py and tag_create.py, to git.py

* Lint code as part of GitHub actions workflow

only for the case where OS is ubuntu-latest and Python version is 3.9

* Added __init__.py in cmdline, command and utilities directories

* Linting updates

1. Linting is a separate job now
2. Disabling some error codes, for now
3. Always return a zero status code

* Hardcoding Python version

* Renaming

* Adding ability to create a mepo binary that can uploaded as an artifact of a Github actions workflow. Pyinstaller requires that the top level script not use relative imports

* Added fix for reading mepo1 state

* Added a mepo command, update-state, to permanently update mepo1 state to mepo2

* Formatting changes to update-state.py

* Slightly different printable representation of component

* Added an optional argument one-per-line for 'list'

* component.py::MepoComponent - renamed to_dict to to_registry_format. Added to_dict

* Fixed test test_list

* Fixed a bug in update-state - need to switch to the fixture dir first

* Implemented a context manager for os.chdir

* Reformatted using black

* Separate GitHub workflows for running linter and formatter

* Added black to requirements

* Using poetry to manage dependencies and packaging

* Added creation of a top level script to build

* Added pylint as (poetry) dependency

* Added pylint to requirements.txt

* Updated pyproject.toml

* Small changes to the test script for consistency in mepo commands

* Enabled previously disabled Pylint (C)onvention and (E)rror codes

* Added directory containing mepo to PYTHONPATH

* Using contextlib.redirect_stdout instead

* Can't switch to contextlib.chdir as this exists only in 3.11+

* Run 'black --check' instead. Non-zero return code indicates that some files need to be formatted

* Formatted using black

* Config file is now called registry

* Moved fixture/component validation from MepoComponent to Registry

* Reformat using black

* Switched from pkl state file to json

* print() has a flush argument

* Trivial changes

* If mepo1 style state, print warning to run 'mepo update-state'. Updated update-state code.

* Removing hashes from requirements.txt

* Fixed bug in string formatting

* Update comment in registry.py

* Store full path to the fixture dir in state file

* Revert "Store full path to the fixture dir in state file". We want relocability.

This reverts commit 1bc8330.

* Local path saved to state file is relative to fixture directory
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants