Closed reelmatt closed 4 years ago
Good catch on the custom_nodes
directory.
Latest commit should address this bug and also streamlines the two 'dir' methods into one set_dir()
which I quite like.
As soon as this is merged I've got a PR with the front end upload functionality ready to go.
This builds off the initial approach for custom nodes in now-closed #66, in much the same way, but now more refined and now with a change to regular Node classes.
Changed endpoints:
/nodes
->/workflow/nodes
: Retrieves list of Nodes for the front-end to display. Response is structured the same; more on the move to Workflow below./workflow/upload
: Now a generic upload endpoint that can accept Node data files (e.g. CSVs) and now custom Node classes. If nonode_id
is specified in thePOST
body, a file path for the custom node is generated.For custom nodes, no package/import validation is performed on upload. The intended process would be: 1) User uploads custom node file. 2) On success, the front-end calls
/workflow/nodes
again for an updating node listing. 3) Here, if any packages for custom nodes are missing, an error is returned telling the user to install the packages before proceeding.Changes to
workflow.py
:_node_dir
attribute to theWorkflow
classnode_path
accessor method that constructs a path to a given Node file.get_packaged_nodes
: This is the method that handles parsing of pyworkflow and custom nodes. There's documentation in the code, but briefly this:self.node_path
. Each directory is thenode_type
(e.g. 'io', 'manipulation', and now 'custom_nodes') and each file within the directory represents an individual Node class.import lib.import_module
to dynamically load the Class and usesModuleFinder.run_script
to extract any missing packages if the import failed.self._graph
calls to the publicself.graph
. Changesupload_file
to static, and accepting ato_open
file path instead ofnode_id
. See bullet 2 above in Changed endpoints.Changes to
node.py
:This is the biggest change of the PR and should help with modularity/customization moving forward. The main
Node
class is still defined inpyworkflow/node.py
, but now, concrete classes are defined in individual files withinpyworkflow/nodes/<node_type>
directories.Benefits this approach brings are:
import_module('pyworkflow.nodes.' + node_type + '.' + node)
for all node types.nodes.py
file.Testing:
This should not affect any other functionality and all Postman/unit tests continue to pass. To test out custom nodes, you can copy any exiting node (e.g.,
io/read_csv.py
) to thepyworkflow/custom_nodes
directory. If you refresh the front-end, the Node should now appear under 'Custom Nodes' and if you drag it to the workspace, it should work identically to the 'I/O' Read CSV Node, including execution. (If you change the name and/or color attributes in the custom Node file, it is easier to see the different Nodes once in the workspace).TBD:
This addresses question 1 in issue #67 (where do custom nodes live). It still does not address question 2 (installation of missing packages), but it has features in place to help with that (e.g., returning a list of missing package names). @matthew-t-smith had mentioned
docker exec
might be able to runpipenv install
without starting/stopping the container. I think it's probably best to wait for the Docker-ization before tackling package installation to better see how it interacts in that case.