Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard naming conventions and search locations for command files #12

Closed
greg-1-anderson opened this issue Apr 10, 2016 · 9 comments
Closed

Comments

@greg-1-anderson
Copy link
Member

Currently, the CommandFileDiscovery class searches for command files named *Commands.php in directories named CliTools (or src/CliTools).

In Drush, I tried an alternative search pattern, and currently look for command files named "*CommandFile.php" in directories named CommandFiles (or src/CommandFiles).

Ideally, we should decide on a single standard default that both Drush and DrupalConsole can use, so that command files are found consistently. At the moment, I am leaning towards the second option, and calling these literally CommandFiles, as Drush is currently doing. Other conventions are possible, of course; anyone with opinions on the subject should weigh in.

@weitzman
Copy link
Member

No strong opinion here. I think the File suffix is a bit redundant (and Tools as well).

@greg-1-anderson
Copy link
Member Author

Symfony Console searches for *Command.php in Command, so we shouldn't use that.

Other options:

*Commands.php in Commands
*Cli.php in Cli

@greg-1-anderson
Copy link
Member Author

Another thing that would be sensible would be to search for *Commands.php in Command -- same directory as Symfony Console's standard, but a (slightly) different filename. Symfony Console command files implement one command -- annotation command files can provide multiple commands.

@itsdarrylnorris
Copy link

My two cents....

I personally like the structure that Symfony Console provide *Command.php in src/Command. I think is going to be confusing for anyone that have to contribute before to a Symfony Console project and is now trying to contribute to either Drush or Drupal Console.

Since this mainly for support for annotation commands what about *Annotation.php in src/Command/Annotation/ or src/Annotation. This will allow users to either write commands in the Symfony Console way or Annotation way.

@greg-1-anderson
Copy link
Member Author

Yes, I agree that it should be possible to write either a Symfony Console command or a new annotation command. The proposed PR in DrupalConsole, hechoendrupal/drupal-console#2081, supports this.

Annotations can be used for many things other than defining commands, though, so I think that *Annotation.php is a bit too generic, and src/Annotation is a little too hidden. I like sharing src/Command, since that makes the new commands discoverable. src/Command/Annotation is at least in the right location, but I tend to think that someone who was familiar with Symfony would expect to see annotations that affect Symfony commands in that location -- not more commands. *Commands.php has the advantage of being short and visible.

src/Command/*AnnotationCommand.php would also meet all of the criteria, but is a bit long.

@greg-1-anderson
Copy link
Member Author

src/Command/*AnnotatedCommand.php is another viable alternative.

@greg-1-anderson
Copy link
Member Author

I prefer the shorter variation myself, but am not super strongly attached with it, and could go with ^^ if that's what most folks want to see.

@fago
Copy link

fago commented Apr 16, 2016

I think the command classes miss a neat name, "command class instance" is a bit long and clumsy. What about just going with CommandHandler? Then we could use a CommandHandler namespace and have a clear differentation to CommandHandlers that provide multiple commands and Command classes ?

@greg-1-anderson
Copy link
Member Author

Ended up leaving the defaults as they were. Each individual project may set the search locations they prefer, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants