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

MaskOta created an issue. See original summary.

couturier’s picture

Status: Active » Postponed (maintainer needs more info)

I 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?

szeidler’s picture

This 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.

ronan’s picture

does not utilize composer in a proper way

Nope. 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.

szeidler’s picture

Status: Postponed (maintainer needs more info) » Active

But I don't forsee making composer required to install until that process is accessible to all Drupal users.

That'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.

ronan’s picture

> 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

szeidler’s picture

Does that sound about right?

Yes. 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.

Maybe I should rename 'vendor' since it won't be managed by composer any more. Not sure if that will make any difference

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 :-)

ronan’s picture

Status: Active » Fixed

Done. 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

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.