Usually I don't care about unpacking packs ... but I was playing with this feature and tried to run this command:
$ composer unpack
[Symfony\Component\Console\Exception\RuntimeException]
Not enough arguments (missing: "packages").
For those of you who usually unpack packages, what do you think about adding support to unpack all packs at once running the composer unpack command without arguments? Would that be useful ... or is not a common need to unpack everything? Thanks.
I would even add a list of packs that will be unpacked and the dependencies that will be resolved, and add a prompt to ask confirmation to do it 馃憤
And I would even go further: unpack all packs _by default_ when requiring them.
Like composer require symfony/orm-pack would automatically resolve to composer require doctrine/orm doctrine/doctrine-bundle doctrine/doctrine-migrations-bundle instead.
Packs kinda "hide" installed dependencies, and they are even considered as "transient dependencies" in the end, because you don't use what's in the pack, you only use what's _provided_ by the pack (that might change one day).
Like, what if one day symfony/debug-pack doesn't provide Monolog anymore? Or if symfony/serializer-pack stops providing symfony/property-access?
A composer update would remove these, and that's not really a good idea IMO.
I only use packs to install all the things i need. Im unpacking them after that instantly. I don't like the idea of having hidden dependencies in my projects. I like the idea from @Pierstoval to unpack by default. But composer unpack which would unpack everything would be fine for my use case. Or maybe as an option: composer unpack --all just to be explicit?
I would appreciate one of these solution that i don't need to unpack everything manually especially because some packs require packs (amqp-pack requires serializer-pack as an example).
Thumbs up from me 馃憤
I agree to review the operation of the packs as well.
@Pierstoval, we currently have the case with the orm-pack (https://github.com/symfony/orm-pack/blob/v1.0.7/composer.json) which bump doctrine-bundle to version 2 and there's a lot of open issue associated with it because many projects have been broken by this transparency :/
(Of course, it's the developer's duty and common sense, but not for everyone)
I'm not sure that unpacking should be provided as a helper, but listing all existing packs as a suggestion when no packs are provided on the command line could be nice.
$this->getComposer()->getRepositoryManager()->getLocalRepository() should give access to the list of installed packages. Iterating over them to find those with type 'symfony-pack' could be a starting idea to implement this.
PR welcome, help wanted.
If the command composer unpack without arguments is changed to unpack all packs, this should be specified explicitly with an --all option as suggested by @DanielBadura. If composer unpack is run without --all, the message may suggest that the --all option is needed to unpack all packs. This can also be combined with @nicolas-grekas's idea to show all existing packs.
Now that unpacking happens by default, I don't think this will get any tracking.
I'm therefor closing. PR welcome if someone wants to work on it.
Most helpful comment
I would even add a list of packs that will be unpacked and the dependencies that will be resolved, and add a prompt to ask confirmation to do it 馃憤
And I would even go further: unpack all packs _by default_ when requiring them.
Like
composer require symfony/orm-packwould automatically resolve tocomposer require doctrine/orm doctrine/doctrine-bundle doctrine/doctrine-migrations-bundleinstead.Packs kinda "hide" installed dependencies, and they are even considered as "transient dependencies" in the end, because you don't use what's in the pack, you only use what's _provided_ by the pack (that might change one day).
Like, what if one day
symfony/debug-packdoesn't provide Monolog anymore? Or ifsymfony/serializer-packstops providingsymfony/property-access?A
composer updatewould remove these, and that's not really a good idea IMO.