Currently, preferred-install accepts the hash of patterns as the value in the composer.json. I've followed the same approach as used in extra and platform for letting the user define install preferences through CLI in the format: `composer config preferred-install my-organization/stable-package.dist`.
This includes two breaking changes:
- the hostname is not resolved in the case of an IP address.
- a hostname with a trailing period (FQDN) is not matched.
This brings the basic implementation in line with curl behaviour, with
the addition of full IP address and range matching (curl does not
differentiate between IP addresses host names).
The NO_PROXY environment variable can be set to either a comma-separated
list of host names that should not use a proxy, or single asterisk `*`
to match all hosts.
- Port numbers can be included by prefixing the port with a colon `:`.
- IP addresses can be used, but must be enclosed in square brackets
`[...]` if they include a port number.
- IP address ranges can specified in CIDR notation, separating the IP
address and prefix-length with a forward slash `/`.
Commit: 149250ab92
ProcessExecutor::escape handled a false value inconsistently across
platforms, returning an emtpy string on Windows, otherwise `''`. This
is fixed to return `""` on Windows.
The GitDownloaderTest code has been appropriately updated.
Only when a install directory was not specified, was the CWD prepended to `$directory`. This change provides consistency in paths displayed to the user.
Provides feedback output before a potentially long wait on getBestCandidate() call on slow network connections where unresponsiveness/hang may be assumed.
Avoid waiting until after `getBestCandidate()` has finished, as it can add notably delay on slow connections due to downloading megabytes of data. Only to fail if the install location is invalid.
This only removes the credentials if they are managed by composer auth.json or equivalent, if the credentials were present in the package URL to begin with they might remain
Refs #8293Fixes#3644Closes#3608
When the `lock` option is set to false, composer will not write a
`composer.lock` file to disk. This signals that the package is meant
to be developed with unlocked and always updated dependencies. At the
moment, both `install` and `update` are allowed to install the
dependencies for such a package. If #6822 is implemented, only `update`
should be used for packages without a lockfile.
https://github.com/composer/composer/issues/8354
https://www.php.net/strpos has the signature
`strpos ( string $haystack , mixed $needle [, int $offset = 0 ] ) : int`
(The needle is usually the constant)
`strpos('/', $suggestion)` would only be `false` for `''` and `'/'`
So the existing check would just not suggest **anything** that was
already installed (from pecl, built-in, or composer).
The intent seems to be to not suggest non-vendored php packages
that were already installed. (b20cc22ebb)
As described in GH-8289, if no `composer.json` file is found in the current
directory, the user is prompted if she wants to use another `composer.json` file
from a parent directory even if the `COMPOSER_NO_INTERACTION` environment
variable is set. This is fixed here by just moving the check of the environment
variable up in the code so that it is evaluated before the user is prompted.
Composer was unable canonicalize URLs in non-HTTP(S) Composer
repositories. For example it was not possible to use a `providers-url`
in a repository loaded via the `file://` scheme.
See also: #8115
The helper can be included in custom script definitions by calling
"Composer\\Config::disableProcessTimeout".
Example:
{
"scripts": {
"watch": [
"Composer\\Config::disableProcessTimeout",
"vendor/bin/long-running-script --watch"
]
}
}
hhvm-nightly (and next week's release) now report 4.x, so all the 3.x
constraints are now giving misleading error messages with this patch.
Before:
```
- facebook/fbexpect v2.3.0 requires hhvm ^3.28 -> you are running this with PHP and not HHVM.
```
After:
```
- facebook/fbexpect v2.3.0 requires hhvm ^3.28 -> your HHVM version (4.0.0-dev) does not satisfy that requirement.
```
* 1.8:
Fix solver problem exceptions with unexpected contradictory "Conclusions"
Also load config into IO if not freshly created
Only load configuration into IO if IO is available
Fix defaultRepos fallback does not use auth config
This 5 character fix comes with a solver test as well as a functional
installer test essentially verifying the same thing. The solver test is
more useful when working on the solver. But the functional test is less
likely to be accidentally modified incorrectly during refactoring, as
every single package, version and link in the rather complex test
scenario is essential, and a modified version of the test may very well
still result in a successful installation but no longer verify the bug
described below.
Background:
In commit 451bab1c2c from May 19, 2012 I
refactored literals from complex objects into pure integers to reduce
memory consumption. The absolute value of an integer literal is the id
of the package it refers to in the package pool. The sign indicates
whether the package should be installed (positive) or removed (negative),
So a major part of the refactoring was swapping this call:
$literal->getPackageId()
For this:
abs($literal)
Unintentionally in line 554/523 I incorrectly applied this change to the
line:
$this->literalFromId(-$literal->getPackageId());
It was converted to:
-abs($literal);
The function literalFromId used to create a new literal object. By using
the abs() function this change essentially forces the resulting literal
to be negative, while the minus sign previously inverted the literal, so
positive into negative and vice versa.
This particular line is in a function meant to analyze a conflicting
decision during dependency resolution and to draw a conclusion from it,
then revert the state of the solver to an earlier position, and attempt
to solve the rest of the rules again with this new "learned" conclusion.
Because of this bug these conclusions could only ever occur in the
negative, e.g. "don't install package X". This is by far the most likely
scenario when the solver reaches this particular line, but there are
exceptions.
If you experienced a solver problem description that contained a
statement like "Conclusion: don't install vendor/package 1.2.3" which
directly contradicted other statements listed as part of the problem,
this could likely have been the cause.
When a full 'composer' cannot be constructed (because there is no
local composer.json and no global composer.json), some commands
(e.g. `show -a`) fall back to the default repositories from the
`$COMPOSER_HOME/config.json` file. Without this fix, any auth
configuration from `$COMPOSER_HOME/auth.json` is not used for
these repositories in such a fallback scenario.
Steps to reproduce:
* Configure a password-protected composer repository in
`$COMPOSER_HOME/config.json`.
* Configure valid credentials for that repository in
`$COMPOSER_HOME/auth.json`.
* Make sure there is no file `$COMPOSER_HOME/composer.json`.
* Ensure the current working directory has no `composer.json`.
* Run `composer show -a some/package`.
Expected: Information about `some/package` is shown without
needing to enter credentials.
Actual: A prompt "Authentication required" is shown for the
private repository. When running the same command in a dir
that has a `composer.json`, or when `$COMPOSER_HOME/composer.json`
exists, things work as expected.
hhvm-nightly (and the next release) are no longer able to execute
Composer. Support executing Composer with PHP to install dependencies
for hack projects.
The goal is for this to be temporary, until Hack identifies a new
package manager, given that Composer does not aim to be a multi-language
package manager.
fixes#7734
I did not study computer science, so correct me if I'm wrong. But I think you are calculating mebibyte (MiB) not megabyte (MB). Megabyte would be:
... round($valueInByte / 1000 / 1000, 2).'MB ...
Or is there some specific standard you follow? According to https://en.wikipedia.org/wiki/Binary_prefix both calculations (yours and mine) are correct in a way but I find yours to be not completely clear.
The update command can receive a pattern like `vendor/prefix-*`
to update all matching packages.
This has not worked if multiple packages, depending on each other,
where matched to the given pattern. No package has been updated
in this case as only the first package matching the pattern was
added to the whitelist.