Expanding the python path

[liamhuber]

To use pympipool in other repos e.g. `pyiron_workflow, we either need to invoke unit tests from the directory the test files live in, or expand the python path to include those files (cf. this issue and this PR with examples). Unfortunately, github does not make it easy to pass env variables to reusable workflows. So, instead, here I'm introducing a new action for easily adding local directories (i.e. prepending the full runner path to the local repo paths provided) to the python path. It needs to be invoked every job since the env is not shared between jobs, so I've started doing that in the reusable workflows based on a boolean flag input.

I still haven't found a great way to test and debug these workflows, so for the moment the reusable workflow actually has an explicit reference to this branch's tag.

[liamhuber]

When the targets here were set to be self-referential for the branch, it worked like a charm over on pyiron_workflow.

Useage defaults to false, so there's no change for other repos leaning on the centralized CI.

[liamhuber]

Ack, I forgot a thing. Will do it tomorrow.

TODO: add a section on the new action to the readme.

[liamhuber]

@pmrv I see you're active now...could you take a couple minutes and review this for me? It's holding up pyiron_workflow #77 so I'm in a rush, but I would really rather not merge to this repo totally without review.

[pmrv]

I don't follow the workflow details, but if you say you have tested it, it seems an okay work around short term.

I do think messing with sys.path in pympipool is an absolutely terrible idea, that is bound to break other things sooner or later so we should discuss this in a meeting if there's not another way to do it.

[liamhuber]

I don't follow the workflow details, but if you say you have tested it, it seems an okay work around short term.

Good enough for me. It all defaults False anyway so you should only see it if you ask for it.

@jan-janssen and @niklassiemer, you are still extremely welcome to provide post-facto review and I'm happy to patch this accordingly.

[liamhuber]

I do think messing with sys.path in pympipool is an absolutely terrible idea, that is bound to break other things sooner or later so we should discuss this in a meeting if there's not another way to do it.

@pmrv, I don't think anyone's going to disagree with you there. Neither Jan nor I see an alternative atm (although my lack of insight should not be taken too seriously as I'm definitely still not an expert on the async stuff), but I'll add it to the agenda for Monday and we can discuss it in more detail.