I'm finding that VS Code is having trouble locating pydra task packages, which is a bit frustrating because being able to link/peek the source would be very helpful, and I suspect that it is due to the somewhat hacky namespace packaging we are using.
A nice feature of the hatchling build-system (i.e. over flit) is that you are able to design package as a namespace package (i.e. without an __init__.py file in the pkg root) and bundle it with multiple sub-packages (see fileformats for an example).
This means you could turn Pydra into a proper namespace package by removing pydra/__init__.py (moving any required functionality into pydra/engine/__init__.py) and avoid having to use the following hack to the packaging to work properly
The only downside to this is that you wouldn't be able to import selected classes into the Pydra root, e.g. Workflow, ShellCommandTask, and would need to import them from pydra.engine instead. However, I think this might actually make things bit clearer to the user, because it clearly separates the package into tasks for task interfacing, mark for task design and engine for building/running workflows.
I'm finding that VS Code is having trouble locating pydra task packages, which is a bit frustrating because being able to link/peek the source would be very helpful, and I suspect that it is due to the somewhat hacky namespace packaging we are using.
A nice feature of the hatchling build-system (i.e. over flit) is that you are able to design package as a namespace package (i.e. without an
__init__.pyfile in the pkg root) and bundle it with multiple sub-packages (see fileformats for an example).This means you could turn Pydra into a proper namespace package by removing
pydra/__init__.py(moving any required functionality intopydra/engine/__init__.py) and avoid having to use the following hack to the packaging to work properlyThe only downside to this is that you wouldn't be able to import selected classes into the Pydra root, e.g. Workflow, ShellCommandTask, and would need to import them from
pydra.engineinstead. However, I think this might actually make things bit clearer to the user, because it clearly separates the package intotasksfor task interfacing,markfor task design andenginefor building/running workflows.