Request to improve channel management and make default channels removable

[patrk]

Summary

PEAR/PECL installers currently hardcode some default channels (e.g., pecl.php.net, pear.php.net), making it difficult to integrate effectively with enterprise tools like JFrog Artifactory. In situations where an organization needs to proxy external PECL repositories (e.g., for firewall restrictions, network policies, or centralized artifact management), the hardcoded defaults and the inability to delete these channels present significant challenges.

Current Issues

To meet security or network requirements, organizations often use repositories proxied through Artifactory or similar. However, with the current PEAR/PECL setup, attempts to:

1. Use a proxied repository URL encounter errors due to the default channels that are unremovable and hardcoded.
2. Create a seamless installation experience with automatic updates are hindered unless the default channel.xml and metadata are duplicated and altered manually—adding unnecessary maintenance.

This leads to two main suboptimal options:

1. Host a customized channel.xml, which would need continuous mirroring of the original channel while replacing names to work with the installer.
2. Use curl to fetch specific package versions from Artifactory, but this bypasses PECL’s version management features.

Suggested Improvement

Allowing users to delete, override, or alias the default channels (e.g., pecl.php.net and pear.php.net) would give enterprise users greater flexibility to integrate PECL with proxy repositories without complex workarounds or duplications. This change would make the installer more enterprise-friendly, allowing teams to consciously replace channels when it serves their deployment and security needs.

Such an enhancement would make PECL/PEAR more adaptable to modern DevOps practices while retaining the option to use the default channels as they are for standard users.

Thank you for considering this feature request. It would significantly improve PEAR/PECL’s usability in larger organizational setups.

[ashnazg]

We could entertain a PR for this, but PEAR is no longer in active feature development, so it won't happen unless someone contributes it. There are conversations about retiring the PEAR website altogether and leave future package distribution strictly from Github and Packagist, so keep that in mind.