Add initial Python unit/performance tests for TIFF loader module

[gigony]

The main change is for addressing parts of #38 and #61.

• Add initial unit/perf test cases for TIFF loader
• Add license texts for python tests

This also has the following minor changes:

• Fix some typo in the doc.
• Remove cupy_rc channel in README.md
• Update name in Github templates
• Update calculation of patch_down_count

And build/doc related changes

• Update build script and contributing guide
• Fix broken links in docs
• Sort import statements by using isort

./run test                             # execute all tests
./run test python                      # execute all python tests
./run test python unit                 # execute all python unit tests
./run test python unit skimage         # execute all python unit tests in `skimage` module
./run test python unit clara           # execute all python unit tests in `clara` module
./run test python performance          # execute all python performance tests

Current test folder structure looks like below:

python/cucim/tests/
├── __init__.py
├── conftest.py
├── fixtures
│   └── testimage.py
├── integration
│   ├── __init__.py
│   └── clara
│       └── __init__.py
├── performance
│   ├── __init__.py
│   └── clara
│       ├── __init__.py
│       └── test_read_region_memory_usage.py
├── test_cucim.py
├── unit
│   ├── __init__.py
│   └── clara
│       ├── __init__.py
│       ├── test_image_cache.py
│       ├── test_load_image.py
│       ├── test_load_image_metadata.py
│       └── test_tiff_read_region.py
└── util
    ├── gen_image.py
    └── gen_tiff.py

[jakirkham]

Thanks Gigon! 😄

Had a couple suggestions about CI changes that I think we can now drop as well as one question

[ajschmidt8]

Approving ops-codeowner file changes

[gigony]

@jakirkham now it is building. Could you please help review this?

[grlee77]

Hi Gigon, this looks mostly good to me. I left just some minor comments.

The style of passing the image parameters as a string with : separator seems a little un-Pythonic, but this is only for test code, not part of the public API, so I don't have a problem with it.

I have not yet tried running this code, but can try that on the 5th or 6th.

[gigony]

Thank you @grlee77 for the all valuable review! Please help review the updated code.

[grlee77]

Thanks, the test dependency installation looks much cleaner now in the run script.

It would be nice to also update the developer docs to mention how the tests should be run (in CONTRIBUTING.md?)

[gigony]

@grlee77 Addressed your comments.
Please help review them.

The following commits are added:

• Update build script and contributing guide
• Fix broken links in docs
• Sort import statements by using isort

[grlee77]

I reviewed the recent commits, making only a few small suggestions

Thank you for adding the clean and clean_cache options to the run script!

[jakirkham]

Thanks Gigon! 😄

This looks pretty good. Also like the addition of the clean command 🙂

Had a couple minor questions about the environment file

[jakirkham]

Why is this needed?

[gigony]

In Conda package, cudatoolkit package doesn't include nvcc binary, but nvcc is needed to build the project so added it. Does it make sense? Any other solution to do that? :)

[jakirkham]

Yeah it doesn't. We are working on a longer term solution ( conda-forge/cudatoolkit-feedstock#62 )

However this package was added for historical reasons to help users run the CUDA installer. I don't think we should be using it

[gigony]

@jakirkham for now, what would be a good solution until the long-term solution is available?
Currently, without installing cudatoolkit-dev, it would try to find system's nvcc if available which cannot be isolated in the environment. Do you think we can keep the change(cudatoolkit-dev) until the long-term solution is available?

[jakirkham]

Is it ok if we just rely on the system one for now? Or are there other issues with that?

Should add that others may just be using our prebuilt packages. So think this is more a question of what works for us

[gigony]

Is it ok if we just rely on the system one for now? Or are there other issues with that?

I thought env.yml is for setting up 'development environment' to build cuCIM locally from the source code and it is not for the runtime environment (it already has more than needed for just running cuCIM. e.g., yasm/compilers/cmake/flake8 etc).

I don't think all users (developer who want to contribute here) have the same nvcc version needed (in this case, CUDA 11.0) in the system so I think cudatoolkit-dev with the same version of cudatoolkit is needed.

Maybe we need to separate out env.yml -- one for dev, one for runtime.

[gigony]

Hi @jakirkham, can this PR be merged or do I need to address others?

[jakirkham]

@gpucibot merge

[jakirkham]

Thanks Gigon! 😄