Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Drupal should use a single vendor folder for all projects. https://www.drupal.org/node/2380389
Also installing the module with composer duplicates vendor plugins.
Comments
Comment #2
couturier CreditAttribution: couturier as a volunteer commentedI am not seeing either of these problems with the current Backup and Migrate version 8.x-4.x-alpha2 and Drupal 8.3.0. Can you confirm if it still exists for you after upgrading?
Comment #3
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedThis issue is related to the general discussion about the role of composer for backup_migrate in https://www.drupal.org/node/2607038 and https://www.drupal.org/node/2822885 . Currently the github hosted library is integrated into the codebase (in the vendor folder) and does not utilize composer in a proper way.
Comment #4
ronan CreditAttribution: ronan commentedNope. And I'm still undecided how I will handle this in the final release. The goal of this module is to be accessible to all users regardless of technical skill or server setup. I don't think the state of composer in Drupal contrib currently supports this. The packaging is currently awkward because I'm building with composer and deploying the artifact to d.o. If this is causing issues for composer users (it is) then I'll change this. But I don't forsee making composer required to install until that process is accessible to all Drupal users.
Comment #5
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedThat's a valid decision. Then we should remove the backup_migrate_core dependency in the modules composer.json.
Currently it's producing an error when trying to install the module using a composer based workflow. But even fixing this error (tag release/add composer) it would lead to problems when the library is included in the releases.
Comment #6
ronan CreditAttribution: ronan commented> Then we should remove the backup_migrate_core dependency in the modules composer.json
Yeah. That's what I'm planning. I'm thinking just a bare composer.json with the title, description, author and no dependencies will work. Does that sound about right? At least while I figure this mess out? Maybe I should rename 'vendor' since it won't be managed by composer any more. Not sure if that will make any difference
Comment #7
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedYes. And when you have released that change , sites using a composer based workflow can simply download the module with
composer require drupal/backup_migrate
which fails atm.Technically it shouldn't be a difference, but it will be much more clearer that there is no composer dependency. I think otherwise it always would lead to confusion and new open issues here :-)
Comment #8
ronan CreditAttribution: ronan commentedDone. This should now be composer friendly. Just be sure to use `composer require drupal/backup_migrate:4.x-dev` until the next alpha is cut.
Thanks