Add support for pathlib.Path objects as input

[remtav]

Description

Add support for pathlib.Path objects

Fixes #459

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected - these changes will not be merged until major releases!)

How Has This Been Tested?

Please describe tests that you added to the pytest codebase (if applicable).

3 very simple tests have been added to test the core input reading function for vector and raster files. These tests make sure a pathlib.Path object pointing to a file are succesfully read by the different utilities.

Checklist:

• My PR has a descriptive title
• My code follows PEP8
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new errors
• I have added tests that prove my fix is effective or that my feature works
• My PR passes Travis CI tests
• My PR does not reduce coverage in Codecov

If your PR does not fulfill all of the requirements in the checklist above, that's OK! Just prepend [WIP] to the PR title until they are all satisfied. If you need help, @-mention a maintainer and/or add the Status: Help Needed label.

[remtav]

@dphogan This PR would be ready for review. I don't think I can launch CI tests myself. Am I wrong?
Also, I added unit tests for Path object inputs, but I don't think they are essential. I can remove if not necessary.

[remtav]

@dphogan This PR would be ready for review. I don't think I can launch CI tests myself. Am I wrong? Also, I added unit tests for Path object inputs, but I don't think they are essential. I can remove if not necessary.

I must've pinged the wrond contributor...
@rbavery @srmsoumya ?

[rbavery]

Hi @remtav you caught me in a busy month while I've been on vacation or absorbed with project work. I appreciate this PR, looks useful. I'll review it and the policy for launching CI tests next week.

[remtav]

@rbavery have you a chance to take a look? I'll be leaving next monday until mi-august, was trying to close up a few things before leave :)

[rbavery]

@remtav I have not, but it looks like for some reason I don't even have an option to run the CI against your first-time PR. Once I can confirm tests pass this can be merged. This might wait until later this week.

@rodrigoalmeida94 any insight on what I'd need to change to allow CI to run on this PR? looks like in tests.yaml it's set to run on push, which I assume applies to all branches. Since @remtav is a first-time contributor he needs approval I think, but I don't think we are seeing the option we need to approve CI. https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks

[rodrigoalmeida94]

@rbavery I think if you add on: [push, pull_request] instead of just on: push this would allow you to run the workflows against PRs from public forks.

[remtav]

@rbavery friendly reminder about this PR and allowing CI tests for external contributions. Keep us posted.

[rbavery]

@remtav With new PRs, CI/CD should run. Can you open a new PR that is rebased on https://github.com/CosmiQ/solaris/tree/0.5.0 with your changes?

[remtav]

@remtav With new PRs, CI/CD should run. Can you open a new PR that is rebased on https://github.com/CosmiQ/solaris/tree/0.5.0 with your changes?

Ok!