-
Notifications
You must be signed in to change notification settings - Fork 939
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
Remove Drupal Console #89
Comments
When can probably rename the Drupal Console configuration on the
to:
|
@jmolivas That's a good initial step, but the bigger question is whether you as a maintainer of Drupal Console prefer people to have a global installation, or want to promote per-site installs as a best practise? |
I thought the goal with "local drush" was to have one single /vendor with all dependencies resolved in the same dependency pool across web drupal + drush + console + ... i.e if the code runs together (drush runs code from drupal, Drupal console runs code from drupal), then it should be all a single pool of deps in a single /vendor ? Doesn't the same reasoning apply to Drupal console ? |
@yched, I think so too. The project/site dependencies should be managed in the project itself and should not rely on anyone's global installation. This way you make sure the team is working with the intended version. Build and maintenance scripts can rely on the dependencies too and do not have to care about absolute paths. For making the |
Yes, Drupal Console is vulnerable to dependency hell, and should only be used in a project-local context. If you use a global install of Drupal Console, then all of your local and remote instances of Drupal should be at the same version. This typically is not practical. Note that Drush has the 'drush finder' to make it easier to use a site-local Drush as if it were installed globally. Drupal Console could utilize a similar technique. |
Okay, I stand corrected. Thanks, everyone. |
Drupal Console has instructions for global install. I think there's no reason to treat it otherwise.
The main problem with the current approach is that it gets put into vendor/bin/console, while all output actually suggests typing only "drupal" (assuming a global install under the "drupal" name).
This creates confusion in docs, at sprints, etc.
The text was updated successfully, but these errors were encountered: