As discussed in the Drupalcon Core Conversation, we should move the composer.json to the Drupal root, along with adding its meta-information. This allows the project to be properly indexed and read by Composer.

The Symfony and vendor directories are retained in core/vendor.

Files: 
CommentFileSizeAuthor
#11 1805316.patch813 bytesRobLoach
PASSED: [[SimpleTest]]: [MySQL] 53,135 pass(es). View
#5 1806316.patch6.13 KBRobLoach
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1806316.patch. Unable to apply patch. See the log in the details link for more information. View
#3 1805316.patch801 bytesRobLoach
PASSED: [[SimpleTest]]: [MySQL] 42,302 pass(es). View
composer.patch846 bytesRobLoach
PASSED: [[SimpleTest]]: [MySQL] 42,131 pass(es). View

Comments

RobLoach’s picture

Status: Needs review » Needs work

GPL-2.0+ for the license. #1664554: Make composer.json validate

Committed this to my GitHub Drupal 8.x fork, which indexes properly on Packagist. Here's the composer.diff.

webchick’s picture

I committed that, this will need a re-roll.

RobLoach’s picture

Status: Needs work » Needs review
FileSize
801 bytes
PASSED: [[SimpleTest]]: [MySQL] 42,302 pass(es). View

Thanks Angie. Here's the reroll with the move to the project root.

Crell’s picture

FYI, this is going to require manual testing since testbot doesn't do anything with Composer at this point.

RobLoach’s picture

FileSize
6.13 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1806316.patch. Unable to apply patch. See the log in the details link for more information. View

Re-roll. Ran against the latest composer snapshot and it seems to be working. What does testing bot say?

Crell’s picture

Status: Needs review » Postponed

I support this, but postponing on #1894002: Update vendor libraries and pin them to specific versions in composer.json which is guaranteed to conflict.

jibran’s picture

Status: Postponed » Needs review

Restoring status as per #6

jibran’s picture

#5: 1806316.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Proudly Found Elsewhere, +composer

The last submitted patch, 1806316.patch, failed testing.

RobLoach’s picture

RobLoach’s picture

Status: Postponed » Needs review
FileSize
813 bytes
PASSED: [[SimpleTest]]: [MySQL] 53,135 pass(es). View
Crell’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Avoid commit conflicts

Applied patch
rm -rf core/vendor
composer.phar install
Run through Drupal install
Profit.

Note that this will conflict with #1658720: Use ClassLoader instead of UniversalClassLoader :-(

RobLoach’s picture

Whichever one gets committed first, I'll be happy to run an easy re-roll.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Looks straight-forward enough.

Committed and pushed to 8.x. Thanks!

cweagans’s picture

Okay, so if I want to pull in a new library with composer for whatever site I'm building with Drupal 8, how do I do that without hacking core? IMO, this introduces the same problem that having .gitignore in the project root caused: you can't change this configuration without hacking core.

RobLoach’s picture

Stick it into your module's composer.json file. Composer Manager helps manage contrib composer.json files.

cweagans’s picture

(BTW, I'm really sorry to come into this issue after it's committed - it wasn't very visible until recently)

Okay, but in that other composer issue (#1398772: composer.json for modules), we were talking about giving contrib modules composer.json files too and then using composer.json at the project root to manage modules in the current installation, and in #1886820: Packagist for Drupal Projects, somebody wrote some code to facilitate that workflow without infrastructure changes.

Also, what is the point of having composer.json in the Drupal root directory anyways? From what I understand, it's so that packagist can list Drupal as a library to pull into a project. However, Drupal (as viewed from DRUPAL_ROOT) is not a library and it would be (IMO) kind of pointless to try to pull Drupal in and use it as a library. In addition, this breaks the /core idea that we were working with (where all of core is contained in /core).

I propose that we roll this back, and instead of having an entire Drupal installation being pulled in as a library, let's just expose /core as a library. Wouldn't that make more sense? Am I missing something here?

Crell’s picture

You can use packagist for full-project installs, too. See http://symfony.com/download for the command that Symfony uses.

I don't know if Drupal would work with such a command yet... but it would be really cool if it did.

Grayside’s picture

In Composer terms, I think Profile > Drupal Core. You install vanilla Drupal with the core composer.json, not a specific distribution or site.

Status: Fixed » Closed (fixed)

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

chx’s picture

Issue tags: -Avoid commit conflicts

Removing Avoid commit conflicts tag.

Eronarn’s picture

I propose that we roll this back, and instead of having an entire Drupal installation being pulled in as a library, let's just expose /core as a library. Wouldn't that make more sense? Am I missing something here?

I find some appeal in having the Drupal project as a library under /core. However, that would make index.php being outside of /core a little weird, no? (Unless we make the root directory a "drupal" package with its own composer.json requiring the "drupal-core" library.)

tstoeckler’s picture

Issue summary: View changes

FWIW https://github.com/tstoeckler/drupal-core would be a lot easier if this were rolled back or at least a second composer.json were added to /core.

davidwbarratt’s picture

I'm really happy about the change in this issue, because "ideally" a projects dependencies should be managed in the root's composer.json file. However, I think we ought to think of Drupal core as a dependency of someone's drupal site.

As brought up by cweagans, there isn't a way to modify the composer.json file in the root without causing havoc. Because of this I opened #1975220: Allow a Composer user to manage Drupal, modules, and PHP dependencies with a custom root composer.json. Please take a look and let me know what you think.