Hi,
I was wondering if using a local installation profile can improve the workflow with drupal-project.
Right now we add dependencies directly to the composer.json of drupal-project, but maybe we can just pull an installation profile from a subdirectory and have all the project dependencies in the composer.json from the installation profile instead of having them in the main composer.json.
This would be particularly useful in the development phase, it'd allow to test different profiles with the same drupal-project checkout by just changing one line in the main composer.json file.
If there is interest I can try to build a prototype of this idea.
EDIT: maybe someone else has already experimented with that and it turns out it creates more problems than it solves?
Thanks,
Antonio
I think you can use the composer-merge-plugin for this use case.
Hi @webflo, after a quick experiment it looks like it can be done without composer-merge-plugin, using a path repository, along these lines:
diff --git a/composer.json b/composer.json
index dc86929..54ac663 100644
--- a/composer.json
+++ b/composer.json
@@ -13,6 +13,13 @@
{
"type": "composer",
"url": "https://packages.drupal.org/8"
+ },
+ {
+ "type": "path",
+ "url": "local/*",
+ "options": {
+ "symlink": false
+ }
}
],
"require": {
@@ -22,6 +29,7 @@
"drupal/console": "~1.0",
"drupal/core": "~8.0",
"drush/drush": "~8.0",
+ "local/drupal_project_profile": "*",
"webflo/drupal-finder": "^0.2.1",
"webmozart/path-util": "^2.3"
},
With this local/drupal_project_profile/composer.json:
diff --git a/local/drupal_project_profile/composer.json b/local/drupal_project_profile/composer.json
new file mode 100644
index 0000000..2fb7272
--- /dev/null
+++ b/local/drupal_project_profile/composer.json
@@ -0,0 +1,17 @@
+{
+ "name" : "local/drupal_project_profile",
+ "description" : "Drupal-project default installation profile.",
+ "type" : "drupal-profile",
+ "license" : "GPL-2.0+",
+ "repositories": [
+ {
+ "type": "composer",
+ "url": "https://packages.drupal.org/8"
+ }
+ ],
+ "minimum-stability": "dev",
+ "require" : {
+ "drupal/admin_toolbar" : "*",
+ "drupal/pathauto" : "*"
+ }
+}
This allows to specify the "type" field (unlike composer-merge-plugin), which ensures that the profile gets copied under web/profiles/contrib for Drupal to pick it up at site-install time (web/profiles/custom might be more appropriate, tho).
Of course for drush site-install drupal_project_profile
to succeed an actual installation profile must be in local/drupal_project_profile.
The convenience of doing things this way is that we can experiment with different profiles by only changing one line in the drupal-project composer.json achieving a better separation between drupal-project and the actual project.
A downside could be that adding contrib dependencies becomes bit more convoluted:
composer -d=local/drupal_project_profile require --no-update drupal/devel
composer update
Or it can be done by editing local/drupal_project_profile/composer.json by hand and also bumping a "version" field there before calling composer update in the main directory.
However this does not seem to be a big deal for this use case, considering that when using a profile the PROFILE.info.yml needs to be updated anyway to have the new dependencies enabled at site-install time.
To recap, because the composer.json file from drupal-project is still used, the same vendor/ dir is used, and the installers paths are still observed for the drupal projects added via local/drupal_project_profile/composer.json.
Ciao,
Antonio
Wonderful!
Most helpful comment
Hi @webflo, after a quick experiment it looks like it can be done without composer-merge-plugin, using a path repository, along these lines:
With this
local/drupal_project_profile/composer.json:This allows to specify the "type" field (unlike composer-merge-plugin), which ensures that the profile gets copied under
web/profiles/contribfor Drupal to pick it up atsite-installtime (web/profiles/custommight be more appropriate, tho).Of course for
drush site-install drupal_project_profileto succeed an actual installation profile must be in
local/drupal_project_profile.The convenience of doing things this way is that we can experiment with different profiles by only changing one line in the drupal-project
composer.jsonachieving a better separation between drupal-project and the actual project.A downside could be that adding contrib dependencies becomes bit more convoluted:
Or it can be done by editing
local/drupal_project_profile/composer.jsonby hand and also bumping a "version" field there before callingcomposer updatein the main directory.However this does not seem to be a big deal for this use case, considering that when using a profile the PROFILE.info.yml needs to be updated anyway to have the new dependencies enabled at
site-installtime.To recap, because the
composer.jsonfile from drupal-project is still used, the samevendor/dir is used, and the installers paths are still observed for the drupal projects added vialocal/drupal_project_profile/composer.json.Ciao,
Antonio