Move composer.json to the project root

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

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

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

Restoring status as per #6

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

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

Looks straight-forward enough.

Committed and pushed to 8.x. Thanks!

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.

(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: Replace .info.yml with composer.json for extensions), 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?

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.

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

Removing Avoid commit conflicts tag.

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

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.

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.