@alexpott Absolutely. I would also volunteer to work on it to make it a complete tool.
@mallezie the symfony/flex package is a huge pack and done for starting up a boilerplate symfony project with minimal configuration and that might be a jargon for our use case. I've tried that and didn't seem to work out of the box and might need some workaround. So, here's what we can do:
1. Try requiring it in a default project and see if it works. If not, see what work around is required and whether it will be acceptable
2. Think about scalability and how much we want to add features to this plugin pertinent to Drupal recipe.
I've added the suggestion as a features roadmap within the README. I've created the project on Github https://github.com/woredeyonas/Drupal-Recipe-Unpack. Lets created the milestones as issues and continue.
@sonfd, i really appreciate your suggestions. I was especially thinking about the recursive unpacking so would love to clone the project to d.o and collaborate.
I see the issue and completely agree. As one of the aims with the recipe initiative is to allow "application of a recipe at any point within the project cycle" as well as "allowing for updates", i like your suggestion. In that case, we can just update the plugins code to avoid removing the recipe once it unpacks it.
I understand the issue and completely agree. As one of the aims with the recipe initiative is to allow "application of a recipe at any point within the project cycle" as well as "allowing for updates", i like your suggestion. In that case, we can just update the plugins code to avoid removing the recipe once it unpacks it.
I've added pretty constraint reference and should extract the correct version. I've used the the sample recipe composer you provided and getting the following:
"drupal/csp": "^1.0",
"drupal/field_group": "^3.0",
"drupal/gin": "^3.0",
"drupal/gin_login": "^2.0",
"drupal/gin_toolbar": "^1.0",
"drupal/memcache": "^2.0",
"drupal/menu_block": "^1.0",
"drupal/metatag": "^1.0",
"drupal/pathauto": "^1.0",
"drupal/redirect": "^1.0",
"drupal/robotstxt": "^1.0",
For the purpose of testing, i had hardcoded the version to *, which might be why you're seeing these issue. As i'm currently working on a startup recipe, i've noticed it as well. Let me update the plugin to account for the provided versions.
Not yet, but will work towards that. It will be a matter of adding some functions to check the constraints and maybe (if needed) provide a interactive session. Right now, the feature available is the ability to unpack the recipes packages into the projects package list and allow you to update them individually. Once the process is done, it removes the package dependency of the recipe from the composer and lock file.
I have created a WIP composer plugin for this functionality and available under https://gitlab.ewdev.ca/yonas.legesse/drupal-recipe-unpack. I'll be adding documentation and further features soon.
Steps:
1. Add the git repos under the projects repositories list as follows:
{
"type": "vcs",
"url": "https://gitlab.ewdev.ca/yonas.legesse/drupal-recipe-unpack.git"
}
2. Run the install of the package and the recipe.
composer require ewcomposer/unpack:dev-master
In my case, for the purpose of testing, i created a custom recipe and used it.
composer require drupal_recipe/startup
Then you just need to run the unpack command to update the projects package list:
composer unpack drupal_recipe/startup
It will update the composer and lock file with the dependencies available in the recipe.
This gave me a headache as well. After some debugging, I'm trying out the update fro 2.14.0 to 2.29 by overriding the dependency in the composer file. You can find a better reference in this blog. So, i'm doing "drupal/ckeditor_font": "1.3 as 1.x-dev", in the composer.json file. However, the update needs to be thoroughly tested and if it works, then you can go up to 3.x.