Full circle 1.0.0a2 #106
Merged
Full circle 1.0.0a2 #106
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…le when it is available
…groovy expressions
…en by latest nf-core/rnaseq workflow
…NXF_HOME directory, make that directory dependant on the staged working directory itself.
…rialization phase.
…athlib.Path` instances. This is needed to try achieving relocatable working directories, needed to relax usage of WfExS from wihin containers
… cannot be installed. Without the fix, the code misinterprets the workflow type was not recognized, and it tries the next available engine.
With the refactor of path handling along the whole codebase, some hidden issues are now arising. One of them is that marshalling and unmarshalling handling was always overwriting preoviously properly marshalled files, which should be already immutable (like stage-stage.yaml and workflow_config.yaml). Due other issues, stage-state.yaml was corrupted in case an execution fails even before the execution itself. With execution-state.yaml, the code was "forgetting" previous executions metadata on each try. Also, uncovered and fixed a mismatch in engine version. When a version is requested, but the selected one is different, it was partially registered in one instance variable but not in another one, so next run was doomed to unexpectedly redo the same work.
…in wfexs_backend.utils.marhsalling_handling.unmarshall_namedtuple .
…ent engines and fetchers.
* Workflow engines and container factories were reading the raw configuration file in order to locate declaration of custom paths for the programs they need for their work. Several method declarations have been changed, in order to minimize what it is passed down to them, so their implementations are not tied to the structure of the general WfExS configuration files. * CWL workflow engine now is able to install cwltool versions which are older than the requested one, in case that version is incompatible with the python interpreter being used. * CWL workflow engine has gained the capability to use custom python interpreters (or intepreters in different paths). This is needed to disengage cwltool installation from WfExS one a bit more. * CWL workflow engine now forces pydot version lower than 3.0.0, due issue common-workflow-language/cwltool#2027
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This alpha release just implements relocatable working directories, which has required an almost full internal transition from string path handling to pathlib.Path . Many internal hidden issues have been fixed along this path.
It also avoids issue common-workflow-language/cwltool#2027 with
cwltool --print-tooland python versions newer than python 3.7 .