Right now composer_manager 8.x-1.0-beta1 adds module requirements to core/composer.json. The original composer.json is copied to composer.core.json, and treated as the core package.
This provides an easy workflow: "cd core && composer drupal-update".
The downside is that the module is modifying core dependencies, which makes core updates harder, every time core is updated, composer manager needs to be reinitialized and "composer drupal-update" run.

Now that #2406681: Add an autoload.php in the repo root to control the autoloader of front controllers has landed to core, we can overwrite the $root/composer.json file instead, following the workflow described in https://www.drupal.org/node/2404989. Basically, it means specifying "drupal/core" as one of the dependencies.

I've written the initial patch for this change, but ran into some issues while testing it. The main issue is clearly described on the documentation page:

Executing composer install will delete everything in your core directory and download the core version from the repository above. Any modifications in core will be lost.

No matter what's in core/, it will be removed and replaced. The current composer.json requirements result in the latest beta being downloaded.
This also means that running composer update will update you from beta to beta, or from dev to dev.
So, if you ran composer update to add library dependencies for a module, you might suddenly end up with a non functional install.

Now, if a beta was installed, we can get the version from system.info.yml, and add that exact requirement to the root composer.json, killing the danger of unintentional beta updates. However, we have no way of knowing which commit a -dev install was rolled from, so we can't do the same there, composer update will always update you to the latest HEAD. Maybe that's okay?

In any case, going from "Composer Manager results in module libraries being added to the core vendor dir" to "Composer Manager results in your core directory being replaced and redownloaded." is a big step, so I want community input. Do we want to go ahead with the big change? Or do we want to stay with the current approach until the module becomes unnecessary, due to people using $root/composer.json as a drush make file (thanks to Drupal Packagist)?

Comments

bojanz’s picture

bojanz commented
Issue summary: View changes
pbuyle’s picture

pbuyle commented

I've not been using D8 but updating core with a composer install is something I'm looking forward to do. I already switched to composer instead of Drush make for Drupal 7. So I don't see it as a weakness.
Editing the /composer.json, -dev users are able to manually set the used commit and ensure future composer update won't break their install. As -dev users, they know, or should know, what they are doing so this does not seems to be a big issue. If composer manager issue a warning when generating a /composer.json with a -dev core, then it is even less a problem.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

As you said, when you are using the subtree/composer-instead-of-drush-make approach, then you don't really need this module.

So it seems like we should make it as easy as possible to use it for those that don't do that.

Having to re-initialize it is a bit problem, but re-creating core/ would also be an issue, especially if you have patches applied, so we'd need a satisfying solution on managing that, I'm not sure that exists?

pbuyle’s picture

pbuyle commented

If you use composer to manage dependencies, including Drupal core, you can apply patches to these dependencies using a Composer plugin such as composer-patches-plugin. Much more like you do with Drush Make, with the added bonus that can use the same solution with non-Drupal projects.

joshtaylor’s picture

joshtaylor commented

Right now, if composer.json was a viable choice, people should be using either "drupal/core": "8.0.0-beta7" or "drupal/drupal": "8.0.0-beta7", so locking down a version should be easy enough.

I have massive concerns about touching anything inside of core, that should be off-limits for contrib modules as this could change at a moments notice and cause breakage.

How will deploys be done with composer manager? `composer update` should never be be run on production, especially as this will blow memory caps on smaller servers, and should be using lock files at that point to lock in versions.

bojanz’s picture

bojanz commented

@joshtaylor
Both of the two methods result in composer.lock files being generated/updated, so you can run composer install on a server.

davidwbarratt’s picture

davidwbarratt commented

Since composer.json has prefer-stable set to TRUE, Composer should always install the latest beta/rc/release of Drupal 8.

There is an alternative to wiping out /core. You could simply copy the dependencies from core/composer.json to composer.json. Although, as you point out, that will require the composer.json to be regenerated.

As for the question of this issue:
"Decide whether to modify /composer.json instead of core/composer.json"

I think that's a no-brainer. A lot of users will probably be ignoring the entire core directory in their git repository:
https://github.com/drupal/drupal/blob/8.0.x/example.gitignore#L10-L12
so making modifications to core/composer.json would be pointless since they wont be saved anyways.

I think most Composer users understand that if they modify composer.json and run composer update they are then updating all dependencies, so if you don't want Drupal to be updated, you need to fix the version of Drupal

There is a work-around to this, you could just do:

composer update some/package someother/package

https://getcomposer.org/doc/03-cli.md#update

That will only update those dependencies (i.e. it will not update Drupal core).

In that way, it might be wise to update the <root>/composer.json and then just document (in the UI?) what command they need to run (i.e. to update the dependencies that need to be updated).

bojanz’s picture

bojanz commented
Title: Decide whether to modify <root>/composer.json instead of core/composer.json » Modify <root>/composer.json instead of core/composer.json

Almost done.

bojanz’s picture

bojanz commented
Status: Active » Fixed

I've given this a lot of thought, and decided the following:

1) The root package (drupal/drupal) replaces the core package (drupal/core) via the "replace" property, core is not redownloaded.
I think this matches the expectation people have of composer_manager ("I don't care about the composer workflow, I just want my modules to work").

2) "composer/installers" is still added so that modules can specify drupal projects as requirements.
This is needed so that we stay compatible with the normal Composer workflow people will start using more and more.

3) We copy the core scripts and (rebased) autoload paths, so that they still work as expected.

This gives us mostly the same workflow as before, but without modifying core/.

Quoting the updated README:


Installation
------------
- Install the Composer Manager module.
- Run the module's init.php script on the command line
  (`php scripts/init.php` from inside the composer_manager module directory).
  This registers the module's Composer command for Drupal core.
- Run `composer drupal-install` from the root of your Drupal directory.

Note that once installation has completed you can run phpunit only from the root:
`./vendor/bin/phpunit -c core`

Workflow
--------
- Download the desired modules (such as Commerce).
- Run `composer drupal-update` from the root of your Drupal directory.
  This rebuilds composer.json and downloads the new module's requirements.
- Install the modules.

  • bojanz committed de822e4 on 8.x-1.x 
    Issue #2452781: Modify <root>/composer.json instead of core/composer....

  • bojanz committed 3b2c021 on 8.x-1.x 
    Issue #2452781 followup: Update PackageManager to read the installed...

Status: Fixed » Closed (fixed)

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