Background
This issue is for tracking the work required for removing pulse and all its dependencies within Qiskit. For convenience, qiskit/utils/deprecate_pulse.py defines a few decorators for deprecating pulse code, namely deprecate_pulse_func, deprecate_pulse_dependency and deprecate_pulse_arg. All pulse deprecations were marked with these decorators (mostly in #13164), so it should be rather easy to locate the code that need to be removed by searching for deprecate_pulse within the codebase.
Details
Most of the changes here are just code removal, but certain cases require special handling for supporting the fact that we don't have pulse anymore. For example, we would want QPY to still be able to load a payload with pulse data in it (likely leading to a partially-specified circuit), possibly notifying the user that pulse data cannot be represented in Qiskit thus it will be ignored. So I think it makes sense to expect that we'll end up having a few PRs for handling all the removal with the vast majority done in one PR with few additional ones to implement specific changes. Furthermore, I think it would help to work against a dedicated branch so we can make progress in parallel without breaking anything in Qiskit main.
Here are the major things that we need to address. If we work against a single branch, we can mark the progress against that branch:
Note that we'll need to remove more code than what is directly deprecated by the deprecate_pulse_* decorators since these were used to ensure deprecation warning coverage but without necessarily marking every piece of code that need to be removed (for example deprecating only the root of a class hierarchy or just the entry point of deprecated logic).
Background
This issue is for tracking the work required for removing pulse and all its dependencies within Qiskit. For convenience,
qiskit/utils/deprecate_pulse.pydefines a few decorators for deprecating pulse code, namelydeprecate_pulse_func,deprecate_pulse_dependencyanddeprecate_pulse_arg. All pulse deprecations were marked with these decorators (mostly in #13164), so it should be rather easy to locate the code that need to be removed by searching fordeprecate_pulsewithin the codebase.Details
Most of the changes here are just code removal, but certain cases require special handling for supporting the fact that we don't have pulse anymore. For example, we would want QPY to still be able to load a payload with pulse data in it (likely leading to a partially-specified circuit), possibly notifying the user that pulse data cannot be represented in Qiskit thus it will be ignored. So I think it makes sense to expect that we'll end up having a few PRs for handling all the removal with the vast majority done in one PR with few additional ones to implement specific changes. Furthermore, I think it would help to work against a dedicated branch so we can make progress in parallel without breaking anything in Qiskit
main.Here are the major things that we need to address. If we work against a single branch, we can mark the progress against that branch:
qiskit/pulsevisualization/pulse_v2PulseGates,RXCalibrationBuilder,RZXCalibrationBuilder,EchoRZXWeylDecomposition,ValidatePulseGatesgenerate_preset_pass_manager(),PassManagerConfig,generate_scheduling(),transpileDAGCircuitandDagDependency- calibrations support (also in Rust)QuantumCircuit- calibrations supportScheduleBlockindump()QobjToInstructionConvertersequence(),schedule(),schdule_circuit(),assemble_schedules(),ScheduleConfig()and scheduling related methodsGenericBackendV2- make pulse-agnostic (no pulse_channel and custom calibrations in init)tests/python/pulse)test/python/visualization/pulse_v2)deprecate_pulse.pyinqiskit/utilsNote that we'll need to remove more code than what is directly deprecated by the
deprecate_pulse_*decorators since these were used to ensure deprecation warning coverage but without necessarily marking every piece of code that need to be removed (for example deprecating only the root of a class hierarchy or just the entry point of deprecated logic).