If #1475510: Remove symfony components from the core repo and let Composer manage the dependencies instead gets decided in favour of removing symfony components from the codebase, drush make will need to process composer.json after cloning core from git.

Here's an initial stab at a patch - just want to have it up here for referencing purposes for now.

Presumably we would also want to move drush composer into drush core if this were to go ahead, will create a ticket for that if/when the time comes.

Files: 

Comments

Do you think that composer.json should live in /composer.json rather than /core/composer.json? Packagist looks for /composer.json, so it might be good to live by the standard.

I saw that your main reason for moving it into /core/ was to avoid the temptation that might exist to edit it. While I agree that it would be nice for it not to be sticking out like a sore thumb in Drupal's root directory, I'm not sure that's a good enough reason to go against the standard :-/

Issue tags:+composer

adding tag

Component:Make» PM (dl, en, up ...)
Status:Postponed» Active

Not a make thing, but pm.

We should check for a composer.json in any project that gets downloaded, and run it if its there. This has been requested and implemented in the composer project already #1433256: Proposal: Composer as a Library Manager.

This would be very simple to implement once #1316322: Add PSR-0 autoloader to drush is in.

StatusFileSize
new89 KB

This is handled in http://drupal.org/project/composer via the hook currently. Attached is a screenshot of it in action.

StatusFileSize
new68.06 KB

Since the hook is executed when a project is downloaded, it also seems to work with drush make.

make-withcomposer.pngsymfony-distro.make

api = 2
core = 7.x
projects[drupal][type] = core
projects[] = devel
projects[] = symfony

Not sure if the hook is executed when it downloads Drupal Core, but it might be worth investigating.

Since other types of downloads (git, wget/curl, svn, bzr) for make don't yet use pm-download, make might require a bit of additional work.

Hm. What about patches? Does the download hook come in after if we add a composer.json by patch?

@patcon If you're looking to run a patched version of a module, you would fork the module, apply the patch to your fork, and instruct your composer.json to use that fork. Drupal.org is very patch-centric, even though we're on git ;-) . As to how that works with .make? I'm not quite sure as I've never had to run a patched module (always pushed patches upstream).

@jhedstrom Do you know if Drush make invokes a post-download hook for those?

@RobLoach That kinda sounds like bullshit :) I've never run a drupal site where I didn't have to patch at least one module, if not multiple.

Unfortunately, patches are still a part of our workflow, and a reasonable requirement as long as d.o. doesn't support proper pull requests. In my opinion, this is the role of drush make. If we get rid of patches, then composer basically replaces make (which I dont mind, but I do think is premature).

@msonnabaum No, it's not bullshit. And it's part of the reason why I have commits in so many projects.

It's easy to run your own fork of a module and instruct Composer to use your fork. Just make a new sandbox, fork in the module, commit your patch, and use "repositories" to use that one instead. git allows us to do this kind of stuff. Seldaek had some thoughts on it. But that discussion is rather off-topic from what's being discussed here... This issue is just about processing composer.json during Drupal Core's make().

Version:» 8.x-6.x-dev
Status:Active» Closed (won't fix)
Issue tags:+needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If desired, you may copy this task to our Github project and then post a link here to the new issue. Please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.