Add should_run policy for when nodes is None

[akshitasure12]

Fixes #137

[Schefflera-Arboricola]

If the parallel implementation can only run with nodes=None then I think can_run would be more appropriate here-- instead of should_run. Also, please always remember to document such details. Thanks!

[dschult]

The current code just implements what NetworkX implements when nodes is not None.
So I interpret this comment as saying we should put the check for nodes is None into the can_run function, and also remove from the parallel code any checking or handling of the nodes parameter. We know its value is None.

Is this what you are meaning @Schefflera-Arboricola ?

[Schefflera-Arboricola]

The current code just implements what NetworkX implements when nodes is not None.

ok, then I think should_run makes sense here-- the existing should_run message isn't very clear about why this backend should not be run when nodes != None

[dschult]

This looks good. I made a suggestion for the error message.
But I wonder if this will be common enough to justify a function in policies. Perhaps it is better as a one-off should-run function. But then upon thinking more I could see many cases where simple splitting on the nodes makes sense when nodes is None and not if e.g. nodes is a single node (or even a small collection of nodes).

So, I think this is the right place for it.
I'll go ahead and approve it now, with final wording of the warning soon to be fixed.

[akshitasure12]

Thank you @Schefflera-Arboricola and @dschult!

I also removed the handling for the case when nodes is not None, since this scenario should never occur after adding should_run_if_nodes_none. However, this leads to test failures. It doesn’t seem ideal to keep code for a case that never runs in nx-parallel-- can this still be merged despite the failing tests?

[dschult]

The test failure shows the difference between "should_run" and "can_run". :)
We should leave the code in place, because while "should_run" says we should not run it, we still can (by specifying the backend parameters for example). If we want to remove that code we should make a can_run function that returns False in this case. Personally, I think we can leave the code in place and provide the should_run. But I can imagine others feeling differently. And we might change our minds on the approach in the future (still developing these kinds of traditions).

[Schefflera-Arboricola]

@akshitasure12 and @dschult could you please merge the main branch into this PR's branch? -- I'm not seeing the option to sync fork for some reason.. once merged with main the CI tests should pass, and we can get this PR into the next release. Thanks!

[akshitasure12]

Hi @Schefflera-Arboricola, I've merged the main branch into the current PR branch :)

[Schefflera-Arboricola]

For a consistent and organized test structure, it would be good to split the tests in this file-- tests that test should_run used in nx-parallel can remain in this file, while tests that test the functionality implemented in should_run_policies.py (i.e. tests with dummy functions, data, etc.) can live in utils/tests/test_should_run_policies.py. (like get_chunks)