Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unpack all packages? #563

Closed
javiereguiluz opened this issue Sep 23, 2019 · 6 comments
Closed

Unpack all packages? #563

javiereguiluz opened this issue Sep 23, 2019 · 6 comments

Comments

@javiereguiluz
Copy link
Member

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.

@Pierstoval
Copy link
Contributor

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.

@DanielBadura
Copy link

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 👍

@maxhelias
Copy link
Contributor

maxhelias commented Dec 19, 2019

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)

@nicolas-grekas
Copy link
Member

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.

@nicolas-grekas nicolas-grekas added this to Javier's in Help Wanted Jul 8, 2020
@ihmels
Copy link

ihmels commented Aug 22, 2020

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.

@nicolas-grekas
Copy link
Member

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.

tgalopin pushed a commit to tgalopin/flex that referenced this issue Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants