Subject: PEAR channel (like github gems, but for PHP)
gems.github.com has changed the way I use ruby. Just like ruby/gems, PHP has a packaging/distribution system called PEAR. I think that running a pear channel would help the PHP community with things like GPL extensions, as well as increasing participation in the community. Thoughts?
Comments are currently closed for this discussion. You can start a new one.
2 Posted by joestump on 16 Dec, 2008 05:27 AM
I'm on the PEAR Group and know the people behind the PEAR channel and PEAR installer code. I've got some experience setting up PEAR channels and could probably help out as well.
Let me know if you want me to feed this upstream for help/support as we'd love to have something simple for PEAR channel creation.
Support Staff 3 Posted by PJ Hyett on 16 Dec, 2008 05:29 AM
Yes, we're interested. None of us are familiar with PEAR, so any help would be appreciated.
4 Posted by Brett Bieber on 16 Dec, 2008 04:05 PM
Excellent idea. I'd be willing to help out as well.
5 Posted by Igor Feghali on 16 Dec, 2008 04:06 PM
That would be awesome indeed.
6 Posted by ieure on 16 Dec, 2008 05:28 PM
Another +1 on this.
7 Posted by Jeff Hodsdon on 16 Dec, 2008 06:04 PM
+1
Support Staff 8 Posted by Tom Preston-Werner on 16 Dec, 2008 07:10 PM
We'd love to do this. The easiest way to move this forward is for you guys to think about exactly what functionality you want, and then write up a short proposal for us to implement. Then we can do a back and forth and find something that we're both happy with. Maybe use gist.github.com to draft a simple proposal and then pass it around?
9 Posted by Michael Gauthier on 16 Dec, 2008 07:23 PM
I think this would be great. I've been thinking the same thing would be great for launchpad.net for a little while. If this service was available on github I'd switch from bzr to git use it.
10 Posted by David Coallier on 16 Dec, 2008 09:00 PM
As the PEAR President I'd like to say that this is a great idea. I am happy to help you in any ways if you need anything and I'm really hyped about this idea ;)
Looking forward in hearing from you and seeing that idea grow !
Support Staff 11 Posted by Tom Preston-Werner on 17 Dec, 2008 01:27 AM
David, that's great! Perhaps you could start the ball rolling by preparing a short proposal about how the GitHub/PEAR integration would work. I'm not very familiar with PEAR, so you'll have a much better idea about what kinds of things we can do on our side to make things work the way you'd like.
12 Posted by kazu.dev on 17 Dec, 2008 05:13 AM
Yes!!!, all this last few days I was thinking on how to make this possible! it is great that you all agree with this feature!! git rocks!
Kazuyoshi Tlacaelel.
Support Staff 13 Posted by Tom Preston-Werner on 19 Dec, 2008 11:36 PM
Anybody had a chance to think about what this integration would look like? Maybe someone can point me to a good description of what being a PEAR channel means and how we'd go about implementing that.
14 Posted by joestump on 20 Dec, 2008 05:45 PM
I've had a little experience setting up PEAR1 [1] channels. I don't think it's appropriate to discuss PEAR2 [1] with regards to GitHub. So the rest of this proposal will be framed around getting PEAR1 channels up initially.
pear channel-discover pear.joestump.netand thenpear install joestump/Package_Nameorpear install joestump/Package_Name-alphaorpear install joestump/Package_Name-x.y.z.Given the rules and regulations of the playing field above, I think that the easiest way to set up GitHub PEAR1 channels would be to do the following:
pear channel-discover joestump.pear1.github.com. PEAR1 allows you to do your own custom channel "short names". To avoid conflicts, I'd make the short names something like "$username-github". I'd then installpear install joestump-github/DB_Virtual.I'm sure Travis Swicegood, David Coallier, Greg Beaver, and Helgi Þorbjörnsson can offer more insight and refinement.
--Joe
[1] PEAR (or PEAR1) is currently undergoing a transition from a mixed PHP4/PHP5 codebase. I'll refer to this older code as PEAR1.
[2] PEAR2 is the next generation of PEAR. It's 100% PHP5, has a new installer, is not backwards compatible, etc.
15 Posted by kazu.dev on 05 Jan, 2009 10:15 AM
I think just one channel is best for example: pear.github.com and make all pear packages in github installable through one channel only! and honestly I think this should be on pears shoulders to make the channels and build a linkage between github repositories and packages. Not github's.
it is a great idea though, I cant wait to pass my code to github! keep rocking guys!
16 Posted by joestump on 05 Jan, 2009 10:23 AM
A single channel won't work for a number of reasons. What if we're both creating a package with the same name? There are a number of other things that makes this nearly impossible to do within PEAR. Maybe Helgi could work on a solution to this problem.
Also, why should this be on PEAR's shoulders? GitHub created a Gems repository for Ruby on Rails developers. That being said, I'm in SF and more than happy to meet up with the GitHub crew to hack on this!
--Joe
17 Posted by kazu.dev on 09 Jan, 2009 10:47 AM
Hi Joe, All
I think that the support github is providing is great! but PEAR is not rubygems. thus If the rubygems guys do something.. it does not mean PEAR should mimic. in my opinion, we should take decisions based on the PEAR's needs.
am trying to see this from the client perspective, it is easier to keep track of one channel rather than figuring out the channel for each independent package.
maybe keeping packages in the same channel will help people to merge code under one package name, and remove those that are obsolete and ignored by everyone.
having one single channel will keep package name duplication in order. having two packages with the same name in two different channels is useless since they will collide when installed anyway. in the other hand I agree that more successful packages should have naming privileges.
about PEAR's shoulders I thought it would be great if PEAR keeps track of all the projects hosted at github.
18 Posted by joestump on 09 Jan, 2009 10:57 AM
I'm not saying it's not easier to track a single channel. I never said that. It's obviously easier to just use a single channel. What I said was that it's technically impossible with the way PEAR channels are implemented without causing massive headaches for both developers and GitHub. With the 1:1 channel:user relationship none of the package naming rules have to be broken and GitHub doesn't have to worry about package collisions.
I don't see a reason to force people to merge packages under the same name just because they're on GitHub. If people want to be "official" PEAR packages then they'll release them as such under pear.php.net (at which point GitHub would just be an unofficial channel). PEAR has rules for package name collisions.
Having two packages with the same name in two separate channels isn't useless at all. It allows me, as a consumer, to choose which one is best and install that one while ignoring the other one. (e.g. pear channel-discover joestump.pear.github.com && pear install joestump-github/DB_Virtual over foobar's DB_Virtual package).
PEAR already allows developers to specify where a package's source is hosted so your last point is technically already implemented.
19 Posted by kazu.dev on 10 Jan, 2009 11:20 AM
I see. and yup, indeed pear leaves the scm link available for customization. am not only on my side am also in yours, your points are valid.
20 Posted by till on 12 Jan, 2009 05:05 PM
@kazu.dev, @Joe
Another reason why seperate channels would work is that when I e.g. "fork" your code repo and release my own (edited) version of the code through the same channel, we'd have a conflict already.
Otherwise I would think that a) only the master-repo can issue a release and b) if we follow "a" then the names are indeed "unique" across the board. But that doesn't make much sense IMHO.
Otherwise, there are a bunch of tutorials how to setup a channel on Google Code and after all, it's primarily a bunch of XML files that are put online and people could easily have "username.pear.github.com" (or something).
Another reason for seperate channels is, let's say I have a paid account on Github and my "non-opensource-software" shouldn't be distributable through the "public" PEAR channel either.
Just food for thoughts!
21 Posted by kazu.dev on 14 Jan, 2009 11:12 PM
Till, yes!
you are right indeed!
22 Posted by kazu.dev on 30 Jan, 2009 01:30 PM
Just want to show this. when run it will fetch & count gems in the github repo.
kazu@utopia:~$ gem list --remote --source http://gems.github.com | wc
2457 4916 70202