i am pretty new with composer and i am having a problem with a download.
I install composer and afterwards i want to install a proyect in beta state trough this command:
composer require google/apiclient:^2.0.0#RC
(This would download the google api client libraries with all their dependencies configurated).
I receive an error telling me that the package is not available in a stable-enough version for my minimum stability settings.
I have read a lot comments from people regarding this issue, but it always involves a composer.JSON file in a local project (not an external download from step 1).
My question is, how could i dowload that project? I would first have to set the minimum stability of composer to "dev" instead of "stable", but how can i do this?
This is what I get:
The windows command shell requires to enclose the package and version into double quotes (and it isn't a bad idea in Linux as well):
Doesn't work in Windows:
composer require google/apiclient:^2.0.0#RC
Does work:
composer require "google/apiclient:^2.0.0#RC"
Please don't set "minimum-stability" to "dev", because this is a global setting and will instantly install development versions that you probably don't want, because they are no final release and may be unstable. This would be true for ALL packages you require, and their dependencies.
SOLUTION: I finally solved it this way:
First you need to create an empty composer.json file wherever you want.
Afterwards you do something like this (or literally this, in my case):
{
"name": "Your title",
"minimum-stability": "dev",
"require":
{
"google/apiclient": "2.0.*"
}
}
Afterwards you go to the directory with this file in the cmd (windows console) and type "composer install".
This will solve the problem and install all the libraries with its dependencies. It is not the same as setting the minimum stability to "dev" for all libraries, but it will solve the problem for specific packages.
Related
According to docs, composer install (composer update too, since it includes install script), among other things, downloads the requirements and puts these packages inside the vendor directory: https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies :
It then implicitly runs the install command. This will download the dependencies' files into the vendor directory in your project.
What the docs don't say is: we often write the following in composer.JSON...
"require": {
"php": "^8.0",
... so if we try to apply what the docs say, it means that Composer would download the PHP interpretor (a package available in Packagist for example) and put it inside the vendor directory, when we run either composer install or composer update. What is the interest of putting a PHP interpretor inside a site's folder (here, vendor)?
But we know it doesn't do that. It won't download any PHP interpretor. It won't obviously put it inside the vendor directory. Instead, it will just check the server's PHP interpretor's version and returns a fatal error or something else if this version doesn't match the requirement's version.
So does it mean that in the Composer's install and update scripts, there is an exception made for PHP when treating the require's lines in the composer.JSON file?
In composer there's a special exception for require php, it only checks if your system's PHP version meets the requirement.
It's in the composer website under Package links: https://getcomposer.org/doc/04-schema.md#package-links.
Its not literally written though, its quite hard to find in the composer documentation.
If your require contains something like with
"php": "^8.0",
"ext-json": "*",
this does not mean: Install PHP or the JSON extension through Composer, but require that PHP and that extension in the given versions are already installed. That's what the documentation at https://getcomposer.org/doc/04-schema.md#package-links tells you:
require and require-dev also support references to specific PHP versions and PHP extensions your project needs to run successfully.
A regular expression that matches all such platform requirements can be found at https://github.com/composer/composer/blob/9ba042ded8b26230d33ebceb692bf29111d51ba4/src/Composer/Repository/PlatformRepository.php#L34 - currently, it contains:
const PLATFORM_PACKAGE_REGEX = '{^(?:php(?:-64bit|-ipv6|-zts|-debug)?|hhvm|(?:ext|lib)-[a-z0-9](?:[_.-]?[a-z0-9]+)*|composer-(?:plugin|runtime)-api)$}iD';
...which matches:
PHP runtimes in several versions
HHVM, a virtual machine that runs a forked version of PHP
all kinds of extensions and core libraries, like ext-json or lib-bz2
Composer itself, as some packages require special features of Composer v2 which were not available in v1
All lines in require section of composer.JSON are not packages available on a repository like Packagist: indeed, we can put some "virtual packages" inside this require section (https://getcomposer.org/doc/01-basic-usage.md#platform-packages).
php is one of these virtual packages. So Composer treat the following line...
"require": {
"php": "^8.0",
... as a virtual package (other name: "plateform package"), and not a package that could be put in vendor.
Then, if we extend a little the following definition of require...
Map of packages required by this package. The package will not be installed unless those requirements can be met.
(https://getcomposer.org/doc/04-schema.md#require)
..., then we can say that "if server's PHP interpretor's version doesn't meet the requirements versions, then Composer will raise a fatal error or something like that.
**Conclusion: being seen as a "virtual/plateform package" by Composer, php won't be installed (put) in vendor directory. It will just make Composer to check if server PHP version matches or not the requirements (if not, an error will be raised). This behavior is different than for other packages that would be, them, downloaded from for example Packagist and installed (put) inside vendor directory. **
Lets say I use TYPO3 7.6 Composer installation. Now I run into following problem:
An Extension in the latest version defines in ext_emconf.php a required TYPO3-Version
'typo3' => '6.0.0-6.2.99',
I tested the Extension already in TYPO3 7 without any problems. In a none composer installation I could install the extension via extension manager and answer the warning with "I know what I'm doing" BUT with composer I can not install the Extension!
I mean yes I could
wait for the developer to update...
fork the extension and change the version in ext_emconf.php :-(
or what?
Is there a way to force composer to install this "incompatible" Extension somehow?
Thanks!
It is not possbile to force an install by composer if the requirements are not met. But there are still a few tricks. You can require TYPO3 7LTS and tell composer to threat it as 6.2. But this of course means that other extensions might now be incompatible. This can be acieved in your composer.json by
"require": {
"typo3/cms": "^7.6 as 6.2.31"
}
If the extension has a development branch that is already combatible and only the release is missing you can require the branch instead of a release. If the extension is registered on packagist.org that would be
"require": {
"vendor/extension": "dev-<branchname>"
}
If it is not registered on packagist but has a composer.json file you can add the repository of the extension to your root composer.json to make the branch requireable.
"repositories": [
{"type": "git", "url": "https://github.com/vendor/extension.git"}
]
But the best way is of course to make the extension compatible and if it already is, to ask for an official release that supports TYPO3 7LTS.
Me and my team are working on a project that uses Composer for dependency management. There seems to be a difference in how a composer update is handled on several machines (running the same latest build version of Composer), but we can't figure out why.
When my teammate runs a composer update on a dependency it tries to remove a lot of data/nodes from the composer.lock file (like the entire dist and support nodes):
When I run the same update, it tries to re-add all those keys again:
We can't figure out why this is happening. Is this a certain setting?
Update: On further inspection, it appears that the "(dis)appearing" nodes all contain https links, could it have something to do with a (missing) SSL library or something?
It seems that one Composer prefers dist and one prefers source.
Look into ~/.composer/config.json if you defined a preferred install in any of your two composers. Or if you defined different preferred installs in the composer.json.
"config": {
"preferred-install": "dist"
}
You can force composer to use either dist or source with
composer update --prefer-dist
or
composer update --prefer-source
--prefer-source: There are two ways of downloading a package: source and dist. For stable versions composer will use the dist by default. The source is a version control repository. If --prefer-source is enabled, composer will install from source if there is one. This is useful if you want to make a bugfix to a project and get a local git clone of the dependency directly.
--prefer-dist: Reverse of --prefer-source, composer will install from dist if possible. This can speed up installs substantially on build servers and other use cases where you typically do not run updates of the vendors. It is also a way to circumvent problems with git if you do not have a proper setup.
Trying to install the KnpGaufretteBundle in a Symfony 2.3 project, I'm having no luck. The problem is:
minimum-stability:stable (in composer.json);
the bundle I require is dev-master version still.
Reading this in the Symfony docs was frustrating:
If you know of a cool bundle or PHP library that still requires a dev
minimum stability, talk to the lead developer and convince him to tag
a stable release.
I'm not changing the minimum stability of the whole project to dev, as it would certainly make a huge mess - I mean, can't I use stable packages and dev packages side by side?
Am I missing something about composer maybe?
Edit (14 August 2013)
According to Sven's answer below, I've edited my composer.json (you can find it here) and it started to work. Anyway, this is a partial solution, because inline aliases do not work for dependencies - so in my case I'd have to specify all dependencies of "less-than-stable" packages first, and alias them one by one.
just use
"knplabs/knp-gaufrette-bundle": "dev-master#dev"
if you need the latest dev version
you can also change minimum-stability to dev and add "prefer-stable": true like this:
"minimum-stability": "dev",
"prefer-stable": true,
then composer will always try to find a stable version and if nothing found install dev, so your symfony packages will be still stable.
But in your case composer will install v0.1.4 (latest stable of knplabs/knp-gaufrette-bundle), so you need dev-master#dev anyway. prefer-stable is just a hint for you.
Have a look at aliases: http://getcomposer.org/doc/articles/aliases.md
They are supposed to allow you to address a branch (which by definition is always in development, because you can only access the latest commit) in a way that that branch should be the logical extension of a version tag.
For a yet untagged project, a proper assumed tag version would be like "0.0.0".
You should try the inline alias for the bundle.
Is there a way to tell composer that each time I do a composer update I want him to ignore a specific package?
Have you considered specifying the required version for the package you are trying to ignore? For instance:
"require": {
"some/package": "~1.2"
}
This may get updated, because you are saying any version >=1.2,<2.0, But if you strictly say you want only version 1.0, you should not see any updates to that package:
"require": {
"some/package": "1.2"
}
Actually I don't know if there is any way to tell composer to exclude one specific package from updating but you can tell which packages to update as
composer update <package> <package2>; // or
php composer.phar update <package> <package2>;
For example,
composer update foo/package1 bar/package2; // or
php composer.phar update foo/package1 bar/package2;
Also, I think, if you don't list them in composer.json (remove after installation) by yourself, then they will not be updated unless also specified in the list.
From Composer:
If you only want to install or update one dependency, you can whitelist them:
$ php composer.phar update monolog/monolog [...]
Check this link and also check Composer.
Update : (found on internet but not tested)
To do that, just remove the package from composer.lock
Update: Only availble for composer versions 1.0.0-alpha6 and lower. Using it in version 1.0.0-alpha7 and higher will remove all packages in "require-dev".
I believe currently you can trick composer with some mess if you can afford it in your project. Something like: Put all packages you don't want to update in "require-dev" and run updates with composer update --no-dev
Just be careful of that if you run composer install as i recall they will be removed from your project.
All this trickery is really nasty, so we should wait for official way of doing things like that, personally i update packages explicitly specifying them
To ignore a specific package, you can use provide (if it's part of your own package) or replace. This tells Composer that you wish to provide/replace a specific package, so it won't download it.
Here is the composer.json file example which should work:
{
"require": {
"radic/tmp-underscore-php": "~1.2.0"
},
"replace": {
"patchwork/utf8": "*"
}
}
In this example, the patchwork/utf8 package would be ignored on composer install or update.
To exclude specific version, see: Composer exclude specific versions.