ORO Packagist issue

[sadortun]

Summary
When performing a composer update or install on platform composer report an issue with ORO Packagist

Steps to reproduce
Looking at the file, there is a big chunk missing at the end.

Actual Result

Expected Result

Details about your environment

• OroPlatform version: x.y.z
• PHP version: x.y.z
• Database (MySQL, PostgreSQL) version

[sadortun]

Also,

Could you please add oro/redis-config to packagist.org ?

  Problem 3
    - The requested package oro/redis-config could not be found in any version, there may be a typo in the package name.

Thanks, Samuel

[anyt]

Fixed. Thank you for the report, Samuel!

[sadortun]

Hi @anyt

Would you be able to add oro/redis-config to packagist.org ? It's the only package from the oro namespace that is missing. ( At least that prevent performing an install without the orocrm repository.

Thanks

[sadortun]

Hi Again @anyt

I am working on some doing some testing with Composer 2.0 and i've found one more thing !

There is an obselete non-updated package composer/composer in the oro packagist that should probably be removed. This is causing issues with composer 2.0.

https://packagist.orocrm.com/?#composer

  Problem 1
    - Root composer.json requires composer/composer 1.6.*, it is satisfiable by composer/composer[1.6.0-RC, ..., 1.6.5] from composer repo (https://repo.packagist.org) but composer/composer[dev-master, 1.0.0-alpha1, ..., 1.0.x-dev (alias of dev-master)] from composer repo (https://packagist.orocrm.com) has higher repository priority. The packages with higher priority do not match your constraint and are therefore not installable. See https://getcomposer.org/repoprio for details and assistance.

FYI For thoses who need a workaround, you can add canonical: false to your repository

   "repositories": {
        "oro": {
            "type": "composer",
            "url": "https://packagist.orocrm.com",
            "canonical": false
        }
    }

FYI # 2 Composer v2.0 reduce the update time by a factor of 3 X , from 1min30 seconds , to 30 seconds. ! Which is amaizing !

[mbessolov]

@sadortun can you share the full composer.json?

Removing a package from the repository is normally a no go - as it will prevent reinstallation of a few (though very old) versions of the app that depend on it. I'm not saying that we support or in any form encourage anyone to use it, but killing a package is not good.

[sadortun]

@mbessolov I am using the github project for theses tests on 4.1 branch

You can test it with composer self-update --snapshot

I understand that removing a package is not a good thing, but

• since the oro packagist composer/composer package was not updated since 2015-04-14
• Default behaviour in composer 2.0 have changed, and since the ORO packagist have priority over packagist.org YOUR composer package will be used for dependency resolution
• Default behaviour of composer 1.x is to look at all repository for matching version.

My guess is that is should be safe to remove it. But it's your call of course ! I only wanted to advise you on the upcoming problem with composer 2.0

Thanks, Samuel

[anyt]

composer/composer was used by our package manager that is not supported anymore. It should be safe to remove it. I'll check, thanks for the notice. But it's not related to the composer version installed globally anyway.

As for the composer update speed, consider installing symfony/flex globally. It speeds up composer operations a lot.

composer global require symfony/flex

The team currently working on composer 2.0 compatibility. We have fixed a few related issues recently.

And for the oro/redis-config it's a question to Michael. Anyway, you'll not be able to use many other oroplatform extensions without Oro's packagist server in composer.json

[sadortun]

@anyt Awesome ! Have a great day !

[mbessolov]

@anyt JFYI, symfony/flex is not compatible with Composer 2.0

[anyt]

same as oro/platform, but composer 2.0 is not released yet. symfony flex with composer 1.0 enables parallel download that is the main performance improvement in composer 2.0 afaik, but it also limits symfony/symfony versions in the dependency tree, so it additionally speeds up update and require operations. with composer 2.0 symfony flex will still be useful for us.