schmittjoh / composer-deps-analyzer Goto Github PK

I want to exclude "some" packages (but not all dev dependencies) from the generated graph, can I have something like this?

<?php

$analyzer = new \JMS\Composer\DependencyAnalyzer();
// $excludedPackages can contain packages which I dont want, say `phpunit`
$graph = $analyzer->analyze($dir, $excludedPackages);

I want to exclude "some" packages (but not all dev dependencies) from the generated graph, can I have something like this?

<?php

$analyzer = new \JMS\Composer\DependencyAnalyzer();
// $excludedPackages can contain packages which I dont want, say `phpunit`
$graph = $analyzer->analyze($dir, $excludedPackages);

I want the analyze function here to support an optional field which enables looking into $dir recursively and add the packages by calling createPackage for each directory with a composer.json and composer.lock.

This feature will help the projects with multiple composer.json to use this visualisation.

I need a way to remove certain packages and their dependencies from the generated graph. How can I do it?

<?php

$analyzer = new \JMS\Composer\DependencyAnalyzer();
// $excludedPackages can contain list of packages which I don't want, say phpunit, etc
$graph = $analyzer->analyze($dir, $excludedPackages);

I know how trivial this is ...

Maybe the spaces can be turned into tabs in all source files?

Currently, the test suite uses composer to temporarily install some packages, analyzes the resulting package set and then removes the packages again. This makes the test suite slow to run, dependent on a decent internet connection and introduces unnecessary dependencies.

Afaikt this is only done in order to generate an up-to-date lock file.

Instead, I'd like to propose to commit the resulting lock file (and perhaps hand-tune the expected parameters).

Thanks for working on this great project! Today, I started putting together a really simple dependency visualization project using your analyzer and it worked out really well! Considering it's probably worth sharing, I'd love to publish it on packagist.

However, your project currently does not have any semantic versioning tags at all, and referencing your master branch via composer is kind of unreliable and cumbersome. As such, I'd like to ask if you could maybe add some tagged versions, perhaps even just a v0.1.0 as-is.

Just in case you're curious, this is what the visualized composer dependency graph for your project looks like:

Anyway to be able to modify this to use it for Satis? It uses pretty much the same JSON format as Composer, except there is no lock file, and thus no packages are installed, which I see as a problem.

I want to exclude "some" packages (but not all dev dependencies) from the generated graph, can I have something like this?

<?php

$analyzer = new \JMS\Composer\DependencyAnalyzer();
// $excludedPackages can contain packages which I dont want, say `phpunit`
$graph = $analyzer->analyze($dir, $excludedPackages);

Currently, we analyze every single package and add all of them to a single graph, no matter if it's a dev and non-dev dependency.

Instead, I'd like to propose we add an option to explicitly ignore dev dependencies, that works pretty much like a composer install --no-dev.

After a quick look it appears like it mostly comes down to ignoring require-dev in composer.json and packages-dev in composer.lock. Special care has to be taken to not separate the resulting graph into two disconnected components, but some basic unit tests should be able to cover this case fairly well.

Refs clue/graph-composer#2

Hi @schmittjoh,

Composer installs

• require dependencies of all package
• require-dev dependencies of only root package

But the composer deps analyser analyses

• require dependencies of all package (ok)
• require-dev dependencies of all package (potentially a lot of packages)

So the composer-deps-analyser not analyse exactly what composer really install. What is for me not consistant. And it analyses more packages than those installed which alters the performance unnecessarily.

For example:

• I create a root package with the only dependency "cocur/slugify": "1.2"
• "cocur/slugify": "1.2" as a require-dev "laravel/framework": "~4.1"

The composer-deps-analyser will analyse "laravel/framework": "~4.1" and the dependency graph of @clue that use this analyser will display the Laravel framework which is not installed by composer since it is a require-dev dependency of a nested package. For me, it has no sense.

There are possibly a lot of require-dev dependencies in a package so we possibly analyse a lot of uninstalled dependencies for nothing. The analyser can take a long time to analyse some useless packages and the graph of @clue can be huge and unreaddable because of these useless packages.

I would like to submit you a PR which removes in function DependencyAnalyzer::analyse() these lines

if (isset($packageData['require-dev'])) {
    foreach ($packageData['require-dev'] as $name => $version) {
        $this->connect($graph, $packageData['name'], $name, $version);
    }
}

For backward compatibility we can add a parameter ignoreNestedDevDeps default to false. And if this parameter is set to true we do not consider nested dev dependency packages:

if (!$this->ignoreNestedDevDeps && isset($packageData['require-dev'])) {
    foreach ($packageData['require-dev'] as $name => $version) {
        $this->connect($graph, $packageData['name'], $name, $version);
    }
}

What do you think of this ?

@clue ?

The current behavior is a bit ambiguous with regards to mixed dev- and non-dev-dependencies: Source packages that list a dependency in both "require-dev" and "require" will only create a single edge.

{
  "require": { "vendor/name": ">=1.2" },
  "require-dev": { "vendor/name": ">=1.3" }
}

Currently, we only create a simple digraph and make sure to not add any parallel edges. However, while I understand the original motivation, in that case it probably makes sense to add two separate edges. This would allow us to address their different properties (version constraint, dev-property etc.).

Also refs (and possibly supersedes) #10.

I want to exclude "some" packages (but not all dev dependencies) from the generated graph, can I have something like this?

<?php

$analyzer = new \JMS\Composer\DependencyAnalyzer();
// $excludedPackages can contain packages which I dont want, say `phpunit`
$graph = $analyzer->analyze($dir, $excludedPackages);

I want to exclude "some" packages (but not all dev dependencies) from the generated graph, can I have something like this?

<?php

$analyzer = new \JMS\Composer\DependencyAnalyzer();
// $excludedPackages can contain packages which I dont want, say `phpunit`
$graph = $analyzer->analyze($dir, $excludedPackages);

I want to exclude "some" packages (but not all dev dependencies) from the generated graph, can I have something like this?

<?php

$analyzer = new \JMS\Composer\DependencyAnalyzer();
// $excludedPackages can contain packages which I dont want, say `phpunit`
$graph = $analyzer->analyze($dir, $excludedPackages);