search

drupal-composer / drupal-parse-composer

:mag: Components used in Drupal-Packagist to parse package information from drupal.org
10 stars 11 forks source link

Remove requirements magic for D8 projects. #44

Closed bojanz closed 8 years ago

bojanz commented 9 years ago

As discussed on IRC.

winmillwill commented 9 years ago

Could someone please summarise the irc discussion? How do drupal 8 projects 'manage their own dependencies'? If running 'composer install' doesn't download everything you need for a working drupal project, then this just breaks everything.

bojanz commented 9 years ago

The discussion is about what gets automatically added for drupal modules and themes. Right now a project like drupal/address gets the added requirement of drupal/field, for example. We want to stop doing that, it's the job of the modules themselves to provide a working composer.json file listing its dependencies (such as drupal/core, other modules, etc).

winmillwill commented 9 years ago

If people have actually finally started listing all their php and drupal module/theme/core requirements in composer.json, then in a way this project has run its course. A much smaller, more maintainable library could be carved out that just deals with navigating drupal.org until people finally figure out that all they need is github and packagist.

What I don't understand about your example though is that drupal/field is in core, so adding it to the composer info just makes the json larger, not incorrect, and doesn't result in any unexpected downloads. What's the actual problem that a user would care about here?

bojanz commented 9 years ago

Actually, trying to require any project with a drupal/field dependency is broken right now, since https://github.com/wikimedia/composer-merge-plugin/pull/73 hasn't landed yet.

And in general it's an example of magic that I don't expect or need as a module author.

winmillwill commented 9 years ago

OK, now I understand the problem. This is unfortunate. The better solution though would be to just blacklist things that are in core, I think.

My concern is that if something is in the info file, then it's obviously a runtime dependency. If there's no tooling to guarantee that the composer metadata references everything in the info file, then we're adding a package maintenance step that will get forgotten and things will just break.

So, can you show me evidence that all module maintainers will guarantee that they have a composer.json and that it will be consistent with the info file?

bojanz commented 9 years ago

I don't need a guarantee. A bad or missing composer.json is a bug report against that project. In the two previous Composer BoFs (LA and Barcelona) we said that's as far as we're willing to go.

webflo commented 8 years ago

We fixed the bug upstream in the merge plugin. I think we don't need this change anymore. Feel free to re-open if you disagree.

bojanz commented 8 years ago

I still think this project has no business modifying other project's requirements.