Add comprehensive tests for pygmt.clib.loading.clib_full_names

[seisman]

Description of proposed changes

This PR adds comprehensive tests for the function pygmt.clib.loading.clib_full_names. Following cases are tested using monkeypatch.

	GMT_LIBRARY_PATH	PATH
case 1	undefined	empty
case 2	defined	empty
case 3	undefined	contains GMT's bin
case 4	defined	contains GMT's bin
case 5	defined but incorrect	contains GMT's bin

Some notes:

1. The tests assume that the CI environment (or our local testing environment) can find the gmt command. Otherwise these tests fail. The assumption is valid for our current CI environments, so I prefer not to make the tests too complicated.
2. The tests only check if clib_full_names() returns a generator and the expected list of names. In these tests, the GMT library is not loaded.
3. The tests increase the coverage of pygmt/clib/loading.py by 2 more lines, thus now it's 💯
4. There is still one rare case that is not tested. On Windows, if GMT's bin path is included in PATH, but GMT's library gmt.dll isn't, then the find_library function (which searches DLLs in PATH) won't find gmt.dll. Thus the length of the returned names list will be -1.

Fixes #

Reminders

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst.
• Write detailed docstrings for all functions/methods.
• If adding new functionality, add an example to docstrings or tutorials.

Slash Commands

You can write slash commands (/command) in the first line of a comment to perform
specific operations. Supported slash commands are:

• /format: automatically format and lint the code
• /test-gmt-dev: run full tests on the latest GMT development version

[seisman]

@weiji14 I'd appreciate it if you can give it a review. The latest CI runs (some are skipped by [skip ci]) are available at https://github.com/GenericMappingTools/pygmt/runs/1915712307.

Please read the PR description first. For the point 4, I think it's possible to simulate this case by monkeypatching the find_library function, but I still don't know how to do it.

There is still one rare case that is not tested. On Windows, if GMT's bin path is included in PATH, but GMT's library gmt.dll isn't, then the find_library function (which searches DLLs in PATH) won't find gmt.dll. Thus the length of the returned names list will be -1.

[weiji14]

Please read the PR description first. For the point 4, I think it's possible to simulate this case by monkeypatching the find_library function, but I still don't know how to do it.

Just one quick comment for now on removal of a fixture. I'll need a bit of a think on how to handle the point 4 case.

There is still one rare case that is not tested. On Windows, if GMT's bin path is included in PATH, but GMT's library gmt.dll isn't, then the find_library function (which searches DLLs in PATH) won't find gmt.dll. Thus the length of the returned names list will be -1.

Why is the length of the returned list from clib_full_names -1? Shouldn't it be 0?

[seisman]

There is still one rare case that is not tested. On Windows, if GMT's bin path is included in PATH, but GMT's library gmt.dll isn't, then the find_library function (which searches DLLs in PATH) won't find gmt.dll. Thus the length of the returned names list will be -1.

Why is the length of the returned list from clib_full_names -1? Shouldn't it be 0?

Sorry, the description is confusing. For this case (i.e., gmt.dll and gmt.exe are not in the same directory, and PATH includes GMT's bin path), the number of names will be one less compared to normal cases.

In normal cases, the list of names would be:

["/path/from/gmt_library_path/gmt.dll", 
 "/path/from/gmt-show-library/gmt.dll", 
 "/path/from/ctypes-find-library/gmt.dll",
 "gmt.dll",
 "gmt_w64.dll",
 "gmt_w32.dll",
]

In this rare case, "/path/from/ctypes-find-library/gmt.dll" is not returned, because find_library won't find gmt.dll in PATH.

[seisman]

Ping @weiji14 to give it a review when possible.

[weiji14]

There is still one rare case that is not tested. On Windows, if GMT's bin path is included in PATH, but GMT's library gmt.dll isn't, then the find_library function (which searches DLLs in PATH) won't find gmt.dll. Thus the length of the returned names list will be -1.

Why is the length of the returned list from clib_full_names -1? Shouldn't it be 0?

Sorry, the description is confusing. For this case (i.e., gmt.dll and gmt.exe are not in the same directory, and PATH includes GMT's bin path), the number of names will be one less compared to normal cases.

In normal cases, the list of names would be:

["/path/from/gmt_library_path/gmt.dll", 
 "/path/from/gmt-show-library/gmt.dll", 
 "/path/from/ctypes-find-library/gmt.dll",
 "gmt.dll",
 "gmt_w64.dll",
 "gmt_w32.dll",
]

In this rare case, "/path/from/ctypes-find-library/gmt.dll" is not returned, because find_library won't find gmt.dll in PATH.

Sorry, I've been meaning to log on to Windows to test the special case but too many things on my plate at the moment. Up to you, but I can either approve this PR now as the other cases look covered (and we handle the special case one another time), or keep this PR open for a little longer.

[seisman]

approve this PR now as the other cases look covered (and we handle the special case one another time)

The special case is very rare and I believe it would be difficult for you to reproduce the case. So I prefer to this option if the current tests look good.

[weiji14]

Yeah, agree that it is quite rare, and probably only happens with a very complicated setup (but will see if someone complains). Good to merge then.