Composer check php version

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

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

Command to show/check required PHP version and exts #4658

Command to show/check required PHP version and exts #4658

Comments

Use-case:
Composer is not very friendly when it comes to generating matching environments for application.

composer show -i -t | grep -o "\-\-\(ext-\|php\).\+" | sort | uniq | cut -d- -f3-

That command gives me list of all required versions of all extensions and php like this:

ext-curl * ext-iconv * ext-pdo * ext-tokenizer * php >= 5.3.0 . php >=5.3,=5.6 

It still needs bit of parsing and sorting to get all information for building matching environment.

Suggestion:
Make composer more machine friendly (CI, CD etc.)

1. Add command to check if all ext/php version requirements are satisfied.
   It would help if composer could check if all extensions and php are matching (non destructive way). So far this is done only on install or update (destructive operations) and only if some dependency has changed or is missing.
2. Add command to list all ext/php version requirements.
   Provide list of final version restrictions per ext/php.

The text was updated successfully, but these errors were encountered:

Thanks I noticed platform packages when researching this issue further.

AFAIK platform requirements are only checked for installs and updates of affected packages, please correct me if that’s not the case.

I am trying to create CI process using docker. Having image with minimal set of extensions reduces build time and size of image compared to generic image.

I would like to use just composer.lock to detect if image matches requirements without installing anything. (for checking if image matches requirements)
Second use-case is to collect platform requirements in aggregated form (one set of min, max constraints instead of N) for building image.

1. Project is installed using secrets in PHP cli only image ignoring platform requirements except PHP of course.
2. Tailored image is build based on requirements.
3. Tailored image is checked if matches platform requirements.
4. Result is copied to tailored image.

By requirements I mean facts collected from composer.lock require packages sections.

Composer was not built to manage php extensions, but there is a PR open that attempts to fill this gap. That still does not quite resolve your use-case though. If this is something you need, you will have to contribute it yourself.

Tagging #3836 we share same need for machine readable set of aggregated constrains
I am ok with writing pull but have to read more code first.

Ping @dzuelke because he did a lot of stuff relating to this for Heroku builds.

I am interested in this feature, here’s use case:

• We define our platform requirements (php, ext) in require
• We use external vendors, each of them can define its platform requirements
• composer.lock is generated
• In our organization we have to list all requirements when we order new machine for our app, so at this point I would like to be able to list all platform requirements which should be met on target platform, so I can make sure everything will be installed in order to work. Since I work with many apps and have many extensions installed it is likely to miss some of the requirements from vendors because they can be satisfied by my localhost without my knowledge. But when we prepare requirements for production machine we need to make sure that we list all platform dependencies.

@mishak87’s command did the trick after some tweaks:

composer show -t | grep -o "\-\-\(ext-.\+\|php \).\+" | sort | uniq | cut -d- -f3- 

( -i is deprecated and it was listing php* packages like phpunit/phpunit ), but it would be really helpful to print resolved platform requirements (minimum/maximum PHP version and so on) in user-friendly way.

Источник

Runtime Composer utilities#

While Composer is mostly used around your project to install its dependencies, there are a few things which are made available to you at runtime.

If you need to rely on some of these in a specific version, you can require the composer-runtime-api package.

Autoload#

The autoloader is the most used one, and is already covered in our basic usage guide. It is available in all Composer versions.

Installed versions#

composer-runtime-api 2.0 introduced a new Composer\InstalledVersions class which offers a few static methods to inspect which versions are currently installed. This is automatically available to your code as long as you include the Composer autoloader.

The main use cases for this class are the following:

Knowing whether package X (or virtual package) is present#

\Composer\InstalledVersions::isInstalled('vendor/package'); // returns bool \Composer\InstalledVersions::isInstalled('psr/log-implementation'); // returns bool

As of Composer 2.1, you may also check if something was installed via require-dev or not by passing false as second argument:

\Composer\InstalledVersions::isInstalled('vendor/package'); // returns true assuming this package is installed \Composer\InstalledVersions::isInstalled('vendor/package', false); // returns true if vendor/package is in require, false if in require-dev

Note that this can not be used to check whether platform packages are installed.

Knowing whether package X is installed in version Y#

Note: To use this, your package must require «composer/semver»: «^3.0» .

use Composer\Semver\VersionParser; \Composer\InstalledVersions::satisfies(new VersionParser, 'vendor/package', '2.0.*'); \Composer\InstalledVersions::satisfies(new VersionParser, 'psr/log-implementation', '^1.0');

This will return true if e.g. vendor/package is installed in a version matching 2.0.* , but also if the given package name is replaced or provided by some other package.

Knowing the version of package X#

Note: This will return null if the package name you ask for is not itself installed but merely provided or replaced by another package. We therefore recommend using satisfies() in library code at least. In application code you have a bit more control and it is less important.

// returns a normalized version (e.g. 1.2.3.0) if vendor/package is installed, // or null if it is provided/replaced, // or throws OutOfBoundsException if the package is not installed at all \Composer\InstalledVersions::getVersion('vendor/package');

// returns the original version (e.g. v1.2.3) if vendor/package is installed, // or null if it is provided/replaced, // or throws OutOfBoundsException if the package is not installed at all \Composer\InstalledVersions::getPrettyVersion('vendor/package');

// returns the package dist or source reference (e.g. a git commit hash) if vendor/package is installed, // or null if it is provided/replaced, // or throws OutOfBoundsException if the package is not installed at all \Composer\InstalledVersions::getReference('vendor/package');

Knowing a package’s own installed version#

If you are only interested in getting a package’s own version, e.g. in the source of acme/foo you want to know which version acme/foo is currently running to display that to the user, then it is acceptable to use getVersion/getPrettyVersion/getReference.

The warning in the section above does not apply in this case as you are sure the package is present and not being replaced if your code is running.

It is nonetheless a good idea to make sure you handle the null return value as gracefully as possible for safety.

A few other methods are available for more complex usages, please refer to the source/docblocks of the class itself.

Knowing the path in which a package is installed#

The getInstallPath method to retrieve a package’s absolute install path.

Note: The path, while absolute, may contain ../ or symlinks. It is not guaranteed to be equivalent to a realpath() so you should run a realpath on it if that matters to you.

// returns an absolute path to the package installation location if vendor/package is installed, // or null if it is provided/replaced, or the package is a metapackage // or throws OutOfBoundsException if the package is not installed at all \Composer\InstalledVersions::getInstallPath('vendor/package');

Available as of Composer 2.1 (i.e. composer-runtime-api ^2.1 )

Knowing which packages of a given type are installed#

The getInstalledPackagesByType method accepts a package type (e.g. foo-plugin) and lists the packages of that type which are installed. You can then use the methods above to retrieve more information about each package if needed.

This method should alleviate the need for custom installers placing plugins in a specific path instead of leaving them in the vendor dir. You can then find plugins to initialize at runtime via InstalledVersions, including their paths via getInstallPath if needed.

\Composer\InstalledVersions::getInstalledPackagesByType('foo-plugin');

Available as of Composer 2.1 (i.e. composer-runtime-api ^2.1 )

Platform check#

composer-runtime-api 2.0 introduced a new vendor/composer/platform_check.php file, which is included automatically when you include the Composer autoloader.

It verifies that platform requirements (i.e. php and php extensions) are fulfilled by the PHP process currently running. If the requirements are not met, the script prints a warning with the missing requirements and exits with code 104.

To avoid an unexpected white page of death with some obscure PHP extension warning in production, you can run composer check-platform-reqs as part of your deployment/build and if that returns a non-0 code you should abort.

The default value is php-only which only checks the PHP version.

If you for some reason do not want to use this safety check, and would rather risk runtime errors when your code executes, you can disable this by setting the platform-check config option to false .

If you want the check to include verifying the presence of PHP extensions, set the config option to true . ext-* requirements will then be verified but for performance reasons Composer only checks the extension is present, not its exact version.

lib-* requirements are never supported/checked by the platform check feature.

Autoloader path in binaries#

composer-runtime-api 2.2 introduced a new $_composer_autoload_path global variable set when running binaries installed with Composer. Read more about this on the vendor binaries docs.

This is set by the binary proxy and as such is not made available to projects by Composer’s vendor/autoload.php , which would be useless as it would point back to itself.

Binary (bin-dir) path in binaries#

composer-runtime-api 2.2.2 introduced a new $_composer_bin_dir global variable set when running binaries installed with Composer. Read more about this on the vendor binaries docs.

This is set by the binary proxy and as such is not made available to projects by Composer’s vendor/autoload.php .

Found a typo? Something is wrong in this documentation? Fork and edit it!

Composer and all content on this site are released under the MIT license.

Источник