Closed andre-merzky closed 1 year ago
NOTE: this PR contains #2885 and thus should be merged after that PR.
Hmm, that does not seem to raise a deprecation warning just yet:
Oh! You are right. DeprecationWarning is usually suppressed without -X dev
or another activating case, but it seems that importing and using the deprecated Generics do not raise a run time DeprecationWarning, is consistent with the expectation that typing hints are as close to no-op at runtime as possible.
From PEP-585:
Importing those from typing is deprecated. Due to PEP 563 and the intention to minimize the runtime impact of typing, this deprecation will not generate DeprecationWarnings. Instead, type checkers may warn about such deprecated usage when the target version of the checked program is signalled to be Python 3.9 or newer. It’s recommended to allow for those warnings to be silenced on a project-wide basis.
The deprecated functionality may eventually be removed from the typing module. Removal will occur no sooner than Python 3.9’s end of life, scheduled for October 2025.
So we've got a few years.
At this point in the code we consider it safe to assume that the description targets a worker, so we set it to make sure the downstream code knows what to do. Consider it a service to the end user :-)
Okay... but that means it is not an error to set mode=rp.TASK_EXECUTABLE, and for a Task to have its values silently altered? I don't foresee any real problems, but it seems like a missed opportunity to catch logic errors.
At this point in the code we consider it safe to assume that the description targets a worker, so we set it to make sure the downstream code knows what to do. Consider it a service to the end user :-)
Okay... but that means it is not an error to set _mode=rp.TASKEXECUTABLE, and for a Task to have its values silently altered? I don't foresee any real problems, but it seems like a missed opportunity to catch logic errors.
Yeah, we can issue a warning in those cases.
@mtitov : this is ready for another round of reviews. Thanks!
Attention: Patch coverage is 27.42317%
with 307 lines
in your changes missing coverage. Please review.
Project coverage is 40.66%. Comparing base (
f506c52
) to head (9b327c9
). Report is 3276 commits behind head on devel.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This is a somewhat major overhaul of Raptor and addresses several issues:
request_cb
andresult_cb
are consistently called for all raptor tasksTASK_EXECUTABLE
tasks are correctly routed through raptorstop
command supported right now)One notable semantic change is that the
result_cb
is called beforeAGENT_STAGING_OUTPUT
- raptor is an executor, and just like therequest_cb
is called beforeAGENT_EXECUTING_PENDING
, theresult_cb
is similar bound to theAGENT_EXECUTING
scope.TODO:
master.wait_workers(n)
works as expectedAGENT_EXECUTING
state + comm channels are up and registeredexecutable tasks show up in the
result_cb`This fixes #2731