FIX: enforce code quality/formatting and typing + change to pyproject.toml

[davidsbatista]

So, here is the BIG PR:

• update/cleaned a bit the Makefile:

  • dist change to reflect the change to pyproject.toml
  • added a clean
  • added a lint:
    • black: code formatting for python3.8 and limiting lines to 120 characters long
    • pylint: static code analysis
    • flake8: style enforcing
  • added mypy: type checking with mypy

• added to setup.cfg with flake8 andmypy` configurations

• added pylint.cfg for pylint configuration

• restructured the project according to pyproject.toml:

├── LICENSE
├── README.md
├── pyproject.toml
├── setup.cfg
├── src
│   └── nervaluate
│       ├── __init__.py
│       ├── nervaluate.py
│       └── utils.py
├── tests
│   ├── __init__.py
│   ├── test_evaluator.py
│   ├── test_loaders.py
│   ├── test_nervaluate.py
│   └── test_utils.py
└── tox.ini

• fixed most of the issues raised by pylint, flake8
• added type hints to all functions and make sure there are no issues raised

TESTS:

• I left all the tests as they were and everything passes
• just removed testing with Python 3.7

NOTE:

• class Evaluator still has some issues:too-many-instance-attributes and too-few-public-methods
• the function compute_metrics() is too convoluted and complex, and flake8 and pylint rightful complain.
• I will attend to these issues in a forthcoming PR - the code needs some refactoring

[davidsbatista]

@ivyleavedtoadflax regarding the virtualenv, my bad - I completely forgot to test that one, since I just created a virtual_env install the required dependencies and did all the development there - I will fix it.

Also, the pre-commit is a good idea, makes sense to make the quality code enforcing.

Thanks for your quick feedback.

[davidsbatista]

@ivyleavedtoadflax a suggestion:

Following the same philosophy that I wrote above of running the tests against the development version , why not just make sure the development version we have is on the PYTHONPATH, then one can develop and test/call functions directly without having to install the package after each change in the source code.

Does this makes sense to you ? or I'm missing the whole python of the setup.py step inside the virtualenv on the Makefile?

[nsorros]

@ivyleavedtoadflax a suggestion:

Following the same philosophy that I wrote above of running the tests against the development version , why not just make sure the development version we have is on the PYTHONPATH, then one can develop and test/call functions directly without having to install the package after each change in the source code.

Does this makes sense to you ? or I'm missing the whole python of the setup.py step inside the virtualenv on the Makefile?

I guess a contributor would have to manually change the PYTHONPATH during setup whereas with setup.py develop this happens during the creation of virtualenv so when someone makes changes they are reflected in the same way as setting the PYTHONPATH. So I would argue that is a better flow. Is there any reason for PYTHONPATH that I am missing?

[davidsbatista]

I'm confused with what the setup.py does - isn't it installing the code as a package locally?

If that's the case, this means that for a developer to see changes to code reflected in the current environment he needs to run setup.py again, right?

When I develop I usually create a new env, and then add to the PYTHONPATH the package I'm working on and every time I do import <package> whatever changes I did are already reflected.

[nsorros]

I'm confused with what the setup.py does - isn't it installing the code as a package locally?

If that's the case, this means that for a developer to see changes to code reflected in the current environment he needs to run setup.py again, right?

When I develop I usually create a new env, and then add to the PYTHONPATH the package I'm working on and every time I do import <package> whatever changes I did are already reflected.

python setup.py develop is equivalent to an editable install which what I usually do. And editable install allows you to change the code and rerun without having to update your pythonpath to have the changes reflected. Check this https://setuptools.pypa.io/en/latest/userguide/development_mode.html

[davidsbatista]

Thanks for the pointers @nsorros I've never actually used such a feature from the setuptools, and mostly relied more on PyCharm and/or PYTHONPATH

so, I've solved it by running this:

source .venv/bin/activate && pip3 install --editable .

and the pre-commit now runs code quality-checks:

check yaml...............................................................Passed
black....................................................................Passed
pylint...................................................................Passed
flake8...................................................................Passed
mypy.....................................................................Passed
- hook id: mypy
- duration: 0.13s

Success: no issues found in 3 source files

I can add the tests in a next PR.