- Introduce separate Lock and LocalRepo transactions, one for changes
to the lock file, one for changes to locally installed packages based
on lock file
- Remove various hacks to keep dev dependencies updated and
incorporated the functionality into the transaction classes
- Remove installed repo, there are now local repo, locked repo and
platform repo
- Remove access to local repo from solver, only supply locked packages
- Update can now be run to modify the lock file but not install packages
to local repo
* master:
Follow up to #7946 test: add solver flag to assert path execution
Fix tests
Make sure config command output is also output on --quiet so that warnings can be hidden, fixes#7963
Recognize composer-plugin-api as a platform package, fixes#7951
Quote wildcards to avoid issues in some shells, fixes#7960
Avoid dumping null values for dist reference/shasum and source reference, fixes#7955
Soften hard exit after revert of composer file
Make unixy proxy code POSIX compatible
Update aliases.md
Same but for Problem.php
Better error message for present but incompatible versions
Fix inconsistent casing
Don't do (new Foo())->bar() - not 5.3-compatible
Support identifying the HHVM version when not running with HHVM
* master:
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
Add warning/info msg when tweaking disable-tls setting to avoid confusion, fixes#7935
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.
Pool construction depends on the install request now, so only required
packages get loaded, add some structure for future asynchronously
loading composer repositories
Breaking change for the plugin interface so bumping the version of
composer-plugin-api to 2.0.0
First step for a refactoring of the package metadata loading mechanism
It is known that composer update takes a lot of memory: #5915, #5902,
I am playing with a profiler (@blackfireio) to make a demo in my local
PHP meetup (@phpvigo) and I found out a way to use less memory. These
are my first tests:
* Private project using PHP 5.6:
* Memory: from 1.31GB to 1.07GB
* Wall Time: from 2min 8s to 1min 33s
* symfony-demo using PHP 7.1 in my old mac book:
* Memory: from 667MB to 523MB
* Wall Time: from 5min 29s to 5min 28s
Not use an array inside conflict rules is this improvement main idea:
```php
<?php
//Memory 38MB
gc_collect_cycles();
gc_disable();
class Rule
{
public $literals;
public function __construct(array $literals)
{
$this->literals = $literals;
}
}
$rules = array();
$i = 0;
while ($i<80000){ //
$i++;
$array = array(-$i, $i);
$rule = new Rule($array);
$rules[] = $rule;
}
```
```php
<?php
//Memory 11.1MB
gc_collect_cycles();
gc_disable();
class Rule2Literals
{
public $literal1;
public $literal2;
public function __construct($literal1, $literal2)
{
$this->literal1 = $literal1;
$this->literal2 = $literal2;
}
}
$rules = array();
$i = 0;
while ($i<80000){ //
$i++;
$rule = new ConflictRule(-$i, $i);
$rules[] = $rule;
}
```
More info https://github.com/composer/composer/pull/6168
Since we no longer have suggest/recommend rules and no longer use any update
or feature rules so packages are removed by default, we do not need weak rules
anymore.
The previous rule was not previously updated to point to the next rule when
removing a middle rule from the watch tree for a literal. This resulted in
jumping from one literal's watch tree to another's, which could then jump
back to the original and cause infinite loop in a case like #265.
Fixes#265
Jordi Boggiano