-
Notifications
You must be signed in to change notification settings - Fork 18
Pre-register or allow easy registration of multiple channels #33
Comments
Security is the main reason. Right now the only channels included by default are hosted on PHP infrastructure, and I think that should be kept. One thing that would ease this exaggerated "problem" is making it easier to discover new channels. Pyrus already does this by prompting the user to add an unknown channel when an install command is executed, instead of failing. For example, installing a package from a new channel: ucommbieber:~ bbieber$ mkdir test
ucommbieber:~ bbieber$ cd test
ucommbieber:test bbieber$ pyrus `pwd` set bin_dir `pwd`/bin
Using PEAR installation found at /Users/bbieber/test
Setting bin_dir in system paths
ucommbieber:test bbieber$ pyrus `pwd` install pear.doctrine-project.org/DoctrineDBAL-beta
Using PEAR installation found at /Users/bbieber/test
Sorry, the channel "pear.doctrine-project.org" is unknown.
Do you want to add this channel and continue?
Please choose:
yes
no
[yes] : yes
Discovery of channel pear.doctrine-project.org successful
Downloading pear.doctrine-project.org/DoctrineDBAL
Connected...
Downloading pear.doctrine-project.org/DoctrineCommon
Connected...
Downloading pear.doctrine-project.org/DoctrineSymfonyConsole
Connected...
Installed pear.doctrine-project.org/DoctrineDBAL-2.1.0RC1
Installed pear.doctrine-project.org/DoctrineCommon-2.1.0RC1
Installed pear.doctrine-project.org/DoctrineSymfonyConsole-2.1.0BETA1 This requires the user to still acknowledge third-party sources for code that is being installed on their systems. Another improvement would be a search command to find available packages. With a channel that aggregates just package information and supports a 'search' command, the "findability" of packages would be greatly improved. As discussed before, all that needs to be done is to write a search command that uses this service. I hacked up a quick project that could serve as this channel information aggregation channel here: Currently uses a mysql backend, with json output for search queries. All submissions are handled through CLI. Thoughts??? |
how about $ pyrus discover-all I also like Brett's search idea very much. All the unix package managers have good search capabilities. Be forewarned that we would need to provide a non-interative option for install in order for .deb/.rpm to work. |
I think we're still OK for non-interactive install. Users can run the standard sequence: channel-discover, then install OR, set auto-discover=1 then install. |
The pyrus The source for the channel information aggregator is available here: https://github.com/saltybeagle/pearhunt and it includes a script to parse the XBEL feed from PEAR and add all the channels which Pyrus can parse. https://github.com/saltybeagle/pearhunt/blob/master/scripts/addXBEL.php I'm not interested in supporting adding "all channels," but I do think these two additions resolve this issue:
|
Given the changes done to http://pear.php.net/channels/ we have an easy to maintain index of all of the known channels out there.
One comment people make frequently is in regard to 'pear's main channel is the only one enabled by default' - http://blog.astrumfutura.com/2011/06/how-would-you-engineer-a-pear2pyrus-distribution-architecture/ for instance.
Why don't we ship pyrus with either all of the channels we know about pre-registered; or provide a 'channel-discover-all' style command, which retrieves an up to date list of channels from a server?
http://pear.php.net/channels/xbel.php is the current machine readable output of the channel index page.
The text was updated successfully, but these errors were encountered: