[Bug] Error when installing Doctrine about flex HOT 10 CLOSED

Update: the same error happens if I try to install orm instead of doctrine/orm (I guess orm is an alias configured in Flex to install DoctrineBundle):

$ composer req orm

Using version ^1.6@dev for doctrine/doctrine-bundle
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files
Executing script make cache-warmup [OK]
Executing script assets:install --symlink --relative %WEB_DIR% [KO]
 [KO]
Script assets:install --symlink --relative %WEB_DIR% returned with error code 1
!!
!!
!!
!!    [LogicException]
!!    To configure the ORM layer, you must first install the doctrine/orm package
!!    .
!!
!!
!!
!!

Installation failed, reverting ./composer.json to its original content.

from flex.

this is not a bug in DoctrineBundle. DoctrineBundle is also useful for people wanting to use only the DBAL part (achieved by not configuring the orm part of the config), so the ORM cannot be a requirement.

from flex.

What we would need is a way for Flex to decide that an alias actually expands to several requirements

from flex.

My comment is a "guesstimate" but I bet 95% of DoctrineBundle users need the ORM and only 5% just use the DBAL. Why optimize for the 5% and complicate for the 95%?

from flex.

What we would need is a way for Flex to decide that an alias actually expands to several requirements

I agree, it would be nice to be able to define some recipes that just install a couple of packages. Ex:

• orm => doctrine/orm + doctrine/doctrine-bundle
• api => orm + api-platform/core + nelmio/cors-bundle
• rad => sensio/generator-bundle + sensio/framework-extra-bundle

Each individual lib or bundle would have its own recipe to be able to be installed separately.

from flex.

@javiereguiluz the remaining 5% cannot force composer to ignore a requirement of the package to skip installing doctrine/orm and all its dependencies. So it would be bad for DoctrineBundle itself to use a hard requirement. We cannot optimize for the 95% at the composer level. We can only force the 95% to become 100%.

This is why I suggested having flex aliases being able to resolve to a set of packages instead of a single package, which would allow Flex to optimize the experience.

from flex.

So it would be bad for DoctrineBundle itself to use a hard requirement.

I disagree. If the estimate is accurate (that's a big "if"), then ORM is not a hard requirement, but a much needed requirement.

What's the worst that will happen to a developer that only needs DBAL and installs a DoctrineBundle that requires both ORM and DBAL? They will have some unused package in vendor/, but they can remove the doctrine.orm part in config.yml, so it own't hurt their app.

from flex.

@javiereguiluz the ORM also has extra dependencies, which then might cause a conflict in dependency resolution for something you don't need.
Btw, it might even forbid you to update to the latest dev version of DBAL if you need it, due to the ORM forbidding to use the dev version of the next minor release of DBAL.

from flex.

For the ORM issue, the right way is to create a Composer package (what I call a pack) that bundles what we want for the orm alias. Here, I've created https://github.com/symfony/orm-pack that depends on both doctrine/orm and doctrine/doctrine-bundle. Then, I have added a recipe for that package to declare the orm alias (in #26). Done :) You get the idea for your other examples.

from flex.

@fabpot I sent a PR to improve the way to create a pack though 😄

from flex.