Unable to unpack packages

[respinoza]

Using composer 1.8.5 and PHP 7.3 (we use private packagist)

If I install symfony like

composer create-project symfony/skeleton my-project
composer create-project symfony/website-skeleton my-project

And then I run composer unpack orm, it just says "Nothing to unpack".
Same for other packs.

Unpack doesn't work either for other projects. Thank you.

Am I missing something?

[fabpot]

Unpack is a way to replace a meta package with its dependencies. After creating a project with the skeleton, orm is not installed, so it cannot be unpacked. If you want to install the ORM, use composer req orm

[nicolas-grekas]

composer req --unpack orm

[respinoza]

@fabpot and that's what is not happening... my composer.json right now has "symfony/orm-pack": "^1.0", my understanding is, you run the unpack action to replace the orm-pack with all the dependencies in that meta package (doctrine and such) and it should remove the meta package orm-pack. No replacing.

@nicolas-grekas I ran composer req --unpack orm and nothing happened. I also tried removing the symfony/orm-pack package and then required it again with the --unpack option and it stills backs the symfony/orm-pack again. I was expecting it to install the dependencies in the meta package (doctrine and such).

This is how composer.json looks (partially)

{
    "type": "project",
    "license": "proprietary",
    "require": {
        "php": "^7.1.3",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "sensio/framework-extra-bundle": "^5.1",
        "symfony/asset": "4.2.*",
        "symfony/console": "4.2.*",
        "symfony/dotenv": "4.2.*",
        "symfony/expression-language": "4.2.*",
        "symfony/flex": "^1.1",
        "symfony/form": "4.2.*",
        "symfony/framework-bundle": "4.2.*",
        "symfony/monolog-bundle": "^3.1",
        "symfony/orm-pack": "^1.0",
        "symfony/process": "4.2.*",
        "symfony/security-bundle": "4.2.*",
        "symfony/serializer-pack": "*",
        "symfony/swiftmailer-bundle": "^3.1",
        "symfony/translation": "4.2.*",
        "symfony/twig-bundle": "4.2.*",
        "symfony/validator": "4.2.*",
        "symfony/web-link": "4.2.*",
        "symfony/yaml": "4.2.*"
    },

I ran composer unpack orm and file is the same (symfony/orm installed, no replacement with doctrine). This happens too with the --unpack version.

[respinoza]

@fabpot I fixed a copy paste problem with my original comment, composer create-project symfony/website-skeleton my-project was used and not the simple skeleton. Still, problem persists and as you can see in my other comment, composer.json has symfony/orm-pack.
Unpack action does nothing.

[fabpot]

I've just tested with the following and it works well:

composer create-project symfony/website-skeleton my-project
cd my-project
composer show | grep orm-pack
  -> orm-pack is here
composer unpack orm
composer show | grep orm-pack
  -> orm-pack is NOT here anymore

[stof]

which version of symfony/flex are you using ? Use composer show -i symfony/flex to get the exact installed version

[respinoza]

@stof I am using flex 1.2.5. Looking how it worked for @fabpot I tried on my personal computer and it works, the only difference at work is the use of private packagist and I can confirm that removing the config for packagist.com in my ~/.composer/config.json makes the unpack action work again.

This is the snippet I removed (this is what packagist.com asks you to add to use their service)

"repositories": {
        "packagist.org": false,
        "redacted": {
            "type": "composer",
            "url": "https://repo.packagist.com/redacted/"
        }
    }

I feel this should work with the use of private packagist, right?
At least for now the workaround is to unpack by temporarily removing the packagist.com config but lets say it is not ideal.

[fabpot]

@respinoza Thanks for investigating this issue. Would you be able to locate the issue and submit a pull request with a fix? I don't have a private packagist, so I don't know how to fix it easily.

[respinoza]

@fabpot I will take a look at my end and if I can fix it, create a PR

[respinoza]

I am going to bring this to the composer project as I found out that when you use a private repository, it is marked as a lazy provider but the providerNames is empty leading to findPackage to not be able to find in my case symfony/orm-pack. They have a comment in the code for lazy packages that says can not determine list of provided packages for lazy repositories, so I guess this is a design/limitation of composer.

[Seldaek]

Do you have a link to the flex source where it does this unpacking? Maybe it'd help me understand.. Because the way I see it, the symfony/orm-pack package should have the list of packages it is replacing already, so flex unpacking should just be replacing that orm-pack with its replaces. I don't see why it calls findPackage at all?

[respinoza]

@Seldaek The call for findPackage is here https://github.com/symfony/flex/blob/master/src/Unpacker.php#L38

As discussed, the return value will be null and the for loop will just continue, no packages added to be unpacked.
And you are right, the simplest way to do that is to just replace the deps we have, I have no idea everything that happens between composer and plugins so I am not sure if that information is always available (lets say, you have a composer.json but no lock and try to unpack). I can see how using the composer API is less brittle than processing it on the flex side.

[Seldaek]

I see.. This use case is fixed in the 2.0 branch of Composer. For the current version perhaps flex should try first to call findPackage on $this->composer->getRepositoryManager()->getLocalRepository() so on the local repo which represents the packages that are installed. That way would be faster and more accurate assuming the vendor dir is present, and if that returns null then calling findPackage on the repository manager as currently done as a fallback would work for most users.

[nicolas-grekas]

@respinoza up for a PR?

[nicolas-grekas]

Applied in #543

[respinoza]

@nicolas-grekas thanks, I no longer have access to packagist and the environment where this was an issue. 🙇‍♂️

[RageZBla]

@nicolas-grekas we have access to packagist.com, we'll do the testing thanks.

[RageZBla]

confirmed it is fixed 🎉

Thanks to everyone involved.