simplesamlphp/composer-module-installer

A Composer plugin that allows installing SimpleSAMLphp modules through Composer.

SimpleSAMLphp

This is the official repository of the SimpleSAMLphp software.

• SimpleSAMLphp homepage
• SimpleSAMLphp Downloads

Please, contribute!

composer-module-installer's Issues

1.3.2 dependency issues

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Root composer.json requires simplesamlphp/simplesamlphp-test-framework ^1.3.2 -> satisfiable by simplesamlphp/simplesamlphp-test-framework[v1.3.2].
- simplesamlphp/simplesamlphp-test-framework v1.3.2 requires php ^8.0 -> your php version (7.4.33) does not satisfy that requirement.

Version v1.1.12 requires PHP 7.4 without stating the dependency

Version 1.1.12 was released on 8/31 and uses Property types in ModuleInstallerPlugin.php however it does not indicate that it requires php 7.4 or above and therefore may get installed in systems running earlier versions and fails.

Since this is a backward compatible change. this may break many workflows. At very least you need to introduce a php version dependency in composer.json.

The following error is shown when installing in PHP 7.3 (which is permitted based on the composer.json dependencies)

Parse error: syntax error, unexpected 'ModuleInstaller' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) in vendor/simplesamlphp/composer-module-installer/src/ModuleInstallerPlugin.php on line 15

composer update fails

Since v1.1.10, I get this error on composer update:

  - Installing simplesamlphp/composer-module-installer (v1.1.10): Extracting archive
Plugin initialization failed (Plugin simplesamlphp/composer-module-installer could not be initialized, class not found: SimpleSAML\Composer\ModuleInstallerPlugin), uninstalling plugin
  - Removing simplesamlphp/composer-module-installer (v1.1.10)

The cause might be the difference between the file path (src/SimpleSamlPhp/Composer/ModuleInstallerPlugin.php) and the namespace (\SimpleSAML\Composer\ModuleInstallerPlugin).

Call to protected method SimpleSAML\Composer\ModuleInstaller::getPackageBasePath()

This is a weird error happening on 1.2.0 when the package gets removed

Call to protected method SimpleSAML\Composer\ModuleInstaller::getPackageBasePath() from scope SimpleSAML\Composer\ModuleInstallerPlugin_composer_tmp1 

trace

[2022-08-31T20:40:07.179Z] Exception trace:
[2022-08-31T20:40:07.179Z]   at phar:///usr/bin/composer/src/Composer/Plugin/PluginManager.php(275) : eval()'d code:60
[2022-08-31T20:40:07.179Z]  SimpleSAML\Composer\ModuleInstallerPlugin_composer_tmp1->uninstall() at phar:///usr/bin/composer/src/Composer/Plugin/PluginManager.php:435
[2022-08-31T20:40:07.179Z]  Composer\Plugin\PluginManager->uninstallPlugin() at phar:///usr/bin/composer/src/Composer/Plugin/PluginManager.php:348
[2022-08-31T20:40:07.179Z]  Composer\Plugin\PluginManager->uninstallPackage() at phar:///usr/bin/composer/src/Composer/Installer/PluginInstaller.php:115
[2022-08-31T20:40:07.179Z]  Composer\Installer\PluginInstaller->uninstall() at phar:///usr/bin/composer/src/Composer/Installer/InstallationManager.php:519
[2022-08-31T20:40:07.179Z]  Composer\Installer\InstallationManager->uninstall() at phar:///usr/bin/composer/src/Composer/Installer/InstallationManager.php:392
[2022-08-31T20:40:07.179Z]  Composer\Installer\InstallationManager->Composer\Installer\{closure}() at phar:///usr/bin/composer/vendor/react/promise/src/FulfilledPromise.php:28
[2022-08-31T20:40:07.180Z]  React\Promise\FulfilledPromise->then() at phar:///usr/bin/composer/src/Composer/Installer/InstallationManager.php:393
[2022-08-31T20:40:07.180Z]  Composer\Installer\InstallationManager->executeBatch() at phar:///usr/bin/composer/src/Composer/Installer/InstallationManager.php:334
[2022-08-31T20:40:07.180Z]  Composer\Installer\InstallationManager->downloadAndExecuteBatch() at phar:///usr/bin/composer/src/Composer/Installer/InstallationManager.php:242
[2022-08-31T20:40:07.180Z]  Composer\Installer\InstallationManager->execute() at phar:///usr/bin/composer/src/Composer/Installer.php:787
[2022-08-31T20:40:07.180Z]  Composer\Installer->doInstall() at phar:///usr/bin/composer/src/Composer/Installer.php:616
[2022-08-31T20:40:07.180Z]  Composer\Installer->doUpdate() at phar:///usr/bin/composer/src/Composer/Installer.php:281
[2022-08-31T20:40:07.180Z]  Composer\Installer->run() at phar:///usr/bin/composer/src/Composer/Command/RemoveCommand.php:298
[2022-08-31T20:40:07.180Z]  Composer\Command\RemoveCommand->execute() at phar:///usr/bin/composer/vendor/symfony/console/Command/Command.php:298
[2022-08-31T20:40:07.180Z]  Symfony\Component\Console\Command\Command->run() at phar:///usr/bin/composer/vendor/symfony/console/Application.php:1024
[2022-08-31T20:40:07.180Z]  Symfony\Component\Console\Application->doRunCommand() at phar:///usr/bin/composer/vendor/symfony/console/Application.php:299
[2022-08-31T20:40:07.180Z]  Symfony\Component\Console\Application->doRun() at phar:///usr/bin/composer/src/Composer/Console/Application.php:343
[2022-08-31T20:40:07.180Z]  Composer\Console\Application->doRun() at phar:///usr/bin/composer/vendor/symfony/console/Application.php:171
[2022-08-31T20:40:07.180Z]  Symfony\Component\Console\Application->run() at phar:///usr/bin/composer/src/Composer/Console/Application.php:138
[2022-08-31T20:40:07.180Z]  Composer\Console\Application->run() at phar:///usr/bin/composer/bin/composer:88
[2022-08-31T20:40:07.180Z]  require() at /usr/bin/composer:29

Should SSP modules require SSP?

First of see #11 (comment)

The error was triggered because my module/theme has a composer require statement. I think the error could also be triggered if another package requires SSP and some default modules.

In my opinion every SSP module MUST depend on SSP directly because it uses code of SSP and/or depends on specific directory structure. SSP is clearly a dependency of SSP modules and should be handled like one.

But I got told that my module shouldn't require SSP.

Whats speaks against it? Why should modules/themes not be dependent on SSP?
The only reason I know is to prevent circular dependencies but this problem already exists because SSP requires all the modules every module requires the module install and the module installer requires SSP - a perfect circular dependency :-)

Require simplesamlphp/simplesamlphp

I ran into an interesting situation where I have a SSP module, installed with this package, but on fresh builds (e.g., on a CI server) the auth module was being installed prior to SSP being installed, and as such the module ended up in [project]/modules instead of under the vendor/simplesaml...modules directory.

Composer's dependency resolution is a bit of a black box to me but I do know it installs using required packages. I would think instead of requiring the various modules to be adjusted, we could just add the require statement to this package? It's not useful outside the context of a SSP install, so that would be a logical place to take care of it?

Do not recognise repositories set in modules composer.json

I you add a repository in the composer.json for a module (usually a private one), the the module do not pick it up, when it install the module, resulting in Composer not being able to resolve the required package.

Issue updating from 1.2 to 1.3

When we update our simplesaml to 1.3 all modules are installed into the root of our project.
I can prevent it by fixing the version in composer.json to 1.2.0 - but why the change in module install path?

It seems to me that ModuleInstaller::getPackageBasePath might be guessing the incorrect path.

The only simplesaml requirement we have is on "simplesamlphp/simplesamlphp": "~1.18"

Modules removed if not updated when simplesamlphp is updated

I'm not sure whether to open this issue here or on the Composer repo, but if you have a composer.json that requires simplesamlphp/simplesamlphp as well as simplesamlphp/composer-module-installer and some simplesamlphp modules, running a composer update that updates simplesamlphp/simplesamlphp ends up removing any simplesamlphp modules that weren't updated at the same time.

The "missing" dependencies are still specified in the composer.lock file, and running a composer install adds them back to the vendor folder. But a composer update resulting in required packages being removed from the vendor folder seems like a bug.

You can replicate this (though it's not as simple an example as would be nice, see Note below) by installing the composer dependencies specified by this composer.lock file, then putting this revised composer.json in place and running a composer update.

The result is that simplesamlphp and the simplesamlphp modules with changes are updated, and the simplesamlphp modules without changes are removed (in the process of the simplesamlphp folder being updated).

Note: This composer file includes dependencies that rely on the Composer Asset Plugin due to their use of the Yii framework, so you'll probably need to run to run something like composer global require "fxp/composer-asset-plugin:^1.2.0" before trying to replicate this issue.

Feature request - enable inbuilt modules

If I am installing simplesamlphp via composer, I may also want to enable some of the modules that come bundled with it. At the moment there seems to be no composer friendly way to do this, would the ability to enable (and disable) the modules that come with the simplesaml package be a feature that this tool would want to do (or should I write my own)

No license information found

I cannot find license information in this repository. Maybe I'm overlooking it, but at least it's not evident...

Composer 2 support

This plugin does not work with composer 2 (snapshot) which requires api version 2.

https://github.com/composer/composer/blob/master/UPGRADE-2.0.md#for-integrators-and-plugin-authors

Feature Request

Just a thought, but would it be possible to specify directories for inclusion? For example, if I have build, tests, src, and dist directories, could I specify that I only wanted the dist directory to be copied into the modules directory?

Composer: prepare for future change

Describe the bug
For additional security you should declare the allow-plugins config with a list of packages names that are allowed to run code. See https://getcomposer.org/allow-plugins You have until July 2022 to add the setting. Composer will then switch the default behavior to disallow all plugins.

To Reproduce
Run a composer install and see the warning above