Skip to content

Commit 9f172e1

Browse files
Revert "Add command signal handler. (#2685)" (#2691)
Reason for removing - this signal handler addresses only a single kind of clean-up, but I had a more generalized and adaptive implementation in mind. If we do it this way, I can imagine more functionality being added into this and it becomes a "kitchen sink" trying to handle more and more different types of situations as they arise.. it conflates many concerns, and the more responsibilities it gains, the harder it gets to refactor it away. What I envisioned is the signal handler setting a flag, or firing a hook, that other parts of terminus's code detect and do their own clean-up when it happens.. so if I'm terminus command X, I decide what needs to happen if I'm interrupted. If what I imagined is infeasible, it's not hard to revert this revert and put this signal handler back, but I'd like to pause on putting it in right away.
1 parent b35b708 commit 9f172e1

File tree

2 files changed

+0
-74
lines changed

2 files changed

+0
-74
lines changed

src/Hooks/CommandSignalHandler.php

Lines changed: 0 additions & 66 deletions
This file was deleted.

src/Terminus.php

Lines changed: 0 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,6 @@
4949
use Symfony\Component\Filesystem\Filesystem;
5050
use SelfUpdate\SelfUpdateCommand;
5151
use Pantheon\Terminus\Hooks\CommandTracker;
52-
use Pantheon\Terminus\Hooks\CommandSignalHandler;
5352
use Symfony\Component\EventDispatcher\EventDispatcher;
5453
use Pantheon\Terminus\Update\UpdateChecker;
5554

@@ -149,9 +148,6 @@ public function __construct(Config $config, InputInterface $input, OutputInterfa
149148
$update_checker->run();
150149

151150
$container->get('eventDispatcher')->addSubscriber($container->get('Pantheon\Terminus\Hooks\CommandTracker'));
152-
$container->get('eventDispatcher')->addSubscriber(
153-
$container->get('Pantheon\Terminus\Hooks\CommandSignalHandler')
154-
);
155151

156152
// We can't use Robo\Application addSelfUpdateCommand because if plugin manager is running it won't be a phar from there.
157153
if (!empty(\Phar::running())) {
@@ -237,9 +233,6 @@ private function configureContainer()
237233
// Command Tracker
238234
$container->add(CommandTracker::class);
239235

240-
// Command Signal Handler
241-
$container->add(CommandSignalHandler::class);
242-
243236
// Install our command cache into the command factory
244237
$commandCacheDir = $this->getConfig()->get('command_cache_dir');
245238
if (!is_dir($commandCacheDir)) {
@@ -337,7 +330,6 @@ private function addBuiltInCommandsAndHooks()
337330
// List of all hooks and commands. Update via 'composer update-class-lists'
338331
$this->commands = [
339332
'Pantheon\\Terminus\\Hooks\\Authorizer',
340-
'Pantheon\\Terminus\\Hooks\\CommandSignalHandler',
341333
'Pantheon\\Terminus\\Hooks\\CommandTracker',
342334
'Pantheon\\Terminus\\Hooks\\Interacter',
343335
'Pantheon\\Terminus\\Hooks\\RoleValidator',

0 commit comments

Comments
 (0)