this post was submitted on
8 points (83% like it)
10 up votes 2 down votes
shortlink:
to anything interesting: news article, blog entry, video, picture...

7
8

Is PEAR the only place for publishing modules? (self.PHP)

submitted ago by sleep_well

I'm working on a flat file database engine for PHP, I wish to publish it somewhere to make it easy to be found. Is PEAR the good/only choice?

Thanks for your advise!

all 31 comments
sorted by:
best
hot
new
controversial
top
old

[–]greut 6 points7 points ago*

Try this: http://github.com

PEAR(2) isn't much popular

[–]Pornhub_dev 3 points4 points ago

Github is pretty good, but i feel that it's not really the best place for PHP Modules, there is a few over there, but not that many PHP developer use it, and it's not that easy to browse.

It's a good alternative to PEAR, but honestly PHP is missing a gem or simply a real modern package repository. There is quite a few initiative (Phark, Packagist,...)out there, but i feel like we need a big PHP players (Zend, Symphony, ...) to either jump on one of them and make it standard for the PHP community.

Or for the PHP Core Team to launch a real initiative. That would do a lot of good for the language.

[–]greut 4 points5 points ago

What do you use for “browsing” PHP modules? Nothing but a search engine and trusting people's recommendations, blog posts, tutorials, … The first step is to publish you code somewhere, pick bitbucket, launchpad, google code, sourceforge, …

“Easy to be found” means somewhere on Google and for that you're on your own.

You can mock something like package repository, dependencies, … using svn:externals, git submodule, …

Thanks for the links, may one of them become popular.

[–]Pornhub_dev 0 points1 point ago

I thought for a while about using theses sites API and gather everything in a better manner. Right now, i use nothing to browse PHP modules, i'll Google away. But i'd love to have a central place, where everything is organize by type (DB, HTTP, Video, Image processing, Graphs, ...), with some sort of upvote/downvote system.

[–]TheVenetianMask 1 point2 points ago*

A general purpose version of the WordPress plugin repository would quickly get a lot of people onboard.

[–]stefgosselin 1 point2 points ago*

I have heard many people complain on PEAR, to the point where I avoid using it in production code in my consultancy work. In my command line scripts and utilities though, I have shamelessly (and happily) used various packages over the years. PEAR has saved me many, many hours of work in my humble career.

I feel PEAR has a bad repution just because it has a bad reputation.

Seriously.

Whenever the subject comes up, I have tried asking gently what exactly is wrong with PEAR and the only answers I get is "it's crappy code ...". Any try to delve deeper gets just brushed off. There is no specific deficiency to be pointed out. People don't use because they heard somewhere it was shitty. A junior I worked with a long time ago was saying he avoided 'corny PEAR classes', yet when asked what classes he had looked into ... blank stare, he had never so much as seen a line of PEAR code. Of course, I can admit that like any other public repo, the code quality varies in those classes.

Building a complex application that is properly structured with PEAR classes would obviously be no easy task, considering there are already full-fledged frameworks out there. To slap small tasks/utility scripts though, anything tried and tested that can save me time is perfectly ok with me. My wife totally agrees. I am not intent on re-inventing the wheel to impress anyone. If it exists, has been tested and does the job, why not use it?

My 2 cents, end of rant, have a good day my friend.

[–]stephencorona 2 points3 points ago

Why PEAR sucks:

  • Packages need to proposed, approved, and voted by committee.
  • Competing packages and frameworks are not allowed.
  • You need to follow their Java-heavy coding standard and design patterns
  • You need to use their (shitty) SVN repo and bug tracker

Basically, if you aren't designing a package with PEAR in mind, it won't make into PEAR without a complete rewrite. RubyGems and NPM have a better model- your own source control (Github, Bitbucket, whatever), your own coding style, competition is encouraged.

[–]stefgosselin 1 point2 points ago

I thought we were talking about code quality here. Ok, since we cannot easily point to bad coding, I will debate the PEAR reviewing process, for fun.

  1. So PEAR sucks because people actually look at what gets thrown in the repo? Have you ever been through a codebase that is not peer-reviewed? Drupal's module section is a good example of coder's gone wild without supervision. I love Drupal, and use many 3rd party modules, but hey ... it's a jungle in there and you have to pick and choose. I could give you many, many examples of badly coded Drupal modules that would of certainly been better off not included in the Drupal repo. You have to pick and choose, and having the packages peer reviewed does weed out a lot of the crap.

  2. Competing packages and frameworks not allowed, this does not alter the code quality one bit. I actually do not mind having people concentrate their effort to make a particular package better, rather than re-inventing the wheel. Again, to use Drupal as an example, one has 3 different options/modules to create relations between content-types. All 3 are incompatible with each other, and all have their pros and cons. It is like this for translations, SSL redirection, adding a WYSIWYG editor, menu builders, and most any other task you try to do in Drupal. This gets very confusing, and leads to incomplete solutions where if they would of merged their ideas, the result would of exceeded the sum of the work that was put in. Instead, one has to waste hours/days to learn the ins-and-outs of every package available for a particular task.

For these reasons, code duplication should be avoided, but that is my opinion.

  1. Any coding standard is better than no coding standard. Right?

  2. Any version control is better than no version control. One does not use a package just because it is hosted in a Git repo, just in the way one should not avoid using a well written class just because it's hosted on a svn repo.

Again, comparing apples to oranges (PEAR vs. RubyGEMS) is pointless, unless one can be specific on the code itself, I see no reason to miss out on the time-saving it brings.

Wife is clapping in the background.

+1'ed your posts for the interesting feedback, thanks guys.

[–]stephencorona 0 points1 point ago

I agree with you in some respects- the code quality of PEAR is often very good, especially with the typically poor quality (generally speaking) of PHP code. My gripe is that you shouldn't have to submit your code for approval or rewrite it to follow their design standards when you're open sourcing a package and you want it easily distributable.

I guess I think that PEAR as a platform sucks and the distribution mechanism is too tied into the PEAR community. Yea yea, you can set up your own channel but it makes cross-channel dependency management a nightmare. It's just not a very good tool.

But I do agree that the packages (well, the ones that haven't been abandoned and still use PHP4 style coding) are typically very high quality.

[–]sleep_well[S] 0 points1 point ago

the weird PEAR coding standing makes me hesitating a lot when consider to contribute to it. It is way too different from many people's common practice. and it has to be followed strictly.

[–]krues8dr 2 points3 points ago

Because it's slow and poorly-written - which I happen to know from first hand experience. You really can't build an enterprise application on it, and it's well-deserving of it's reputation. Stick with something like Symfony and you'll be far happier in the long run.

However, I'm very glad to hear that your wife agrees with you.

[–]stefgosselin -1 points0 points ago*

You do realise that you actually prove my point, just saying something is bad, without any particular reference to specific code deficiences, I would consider hearsay. Not so long ago, everyone was saying the world was flat and held that belief firmly because ... everyone said so.

Slow and poorly-written, etc. I have heard all of this before (many many times), but I have yet to meet someone that can actually pinpoint the specific parts that are poorly-written. More important, for small trivial tasks I have yet to see someone sit down on a tight timeline and write a better class of tested code than what PEAR offers. Maybe you can point me to an example of something you did better than PEAR, but looking at the answers in this thread, PEAR & PECL are pretty much what we have available mainstream. Sure, I avoid some packages (I18N, Translation I am looking at you) but I don't disregard a whole pile of code because of a few bad apples. There are many, many poorly coded apps in Linux repositories, should one avoid Linux because of these? .. Obviously not.

Like ALL other PHP libraries I have had the pleasure/misfortune to work with, bottlenecks need to be addressed with caching (APC, eaccelarator come to mind). To be fair, whatever library/framework you use, PHP in itselfs depends on caching and other mecanisms to scale past a certain point.

I did clearly state that a full-blown app should (obviously) not be hacked up with PEAR classes, but then again, would you consider good-practice using a framework to deliver a couple of cli scripts? In my case I do quite a bit of back-end server scripting and PEAR has often come in handy on those projects where you don't want/need to deploy a framework.

Yes. My wife ... agrees to this post also. ;)

Thanks for the reply friend, I enjoy a good debate & please do not take this as an attack on your opinion. I totally respect your point of view, I just don't share it.

Cheers!

[–]krues8dr 0 points1 point ago

So, it's hearsay without a specific list of details? Interesting. Well, let's see - I'll just open up the PEAR site, grab the first popular download I see and... lo and behold, good old Archive_Tar. Ugly, awful, poorly thought-out code.

So either I'm exceptionally good at randomly picking terrible code, or the evidence supports me as well.

I too enjoy debate. But in the same you're trying to pigeonhole me with this no-specific-reference nonsense, I must retort that if you'd spent any time with a good framework you would never expound the virtues of PEAR again. For serious. I believe even your wife would approve of better code.

[–]stefgosselin 0 points1 point ago

Allright, please point out what does not work in Archive_Tar, (never used it myself).

If you had to slap up a simple script that needs to manipulate tar archives, extract, add files, remove files, list content ... you would actually go and write that yourself? Would your code be fully documented and re-usable? Could you do this in a reasonable time frame? Could you please point out the lines that could be optimised?

I have never used this myself, but looking at this class, I am pretty confident using this, I could do the job in minutes, not days.

Again, just opening a file and saying it is crap is not much of a counter-argument. Anyone can open any PHP file and say that.

I use Drupal, Symphony and lately Silex in my projects. But the backend stuff, server tasks, deployment utilities and such, I have never seen anyone use a framework for that. I guess there are people out there that do.

[–]dshafik 1 point2 points ago

Archive_Tar is used by the PEAR installer, so it's used by thousands of developers, on thousands of archives, successfully, every single day.

[–]dshafik 0 points1 point ago

The problem with PEAR (1), is that it is aging. We know better, as a community, how to do things. We've learned from those around us (ruby, java, .NET) new and different (though not all good) ways to do things.

The majority of PEAR stuff is still PHP 4 compatible.

PEAR 2 (pyrus) is shaping up pretty nicely, and brings PEAR into the PHP 5.3+ era.

I find that the most compelling feature of PEAR (1) these days, is the package manager and channels functionality. It is a great distribution and dependency system, as evidenced by tools like PHPUnit and many frameworks that use it successfully.

Perhaps you missed the fact that your vaunted Symfony (yes, Symfony 2 even!) is available via a PEAR channel?

I've written about a dozen packages for PEAR; though almost a decade ago now, it had and still has a great framework around development. Well documented (and accepted!) code standards, peer review, and good revision control workflow.

Am I proud of my old code? Yes. Would I use it today? Probably not.

[–]milki_ 0 points1 point ago

Ehm. That's your complaint? PEAR is compatible with PHP4?

I never understood this. Why is everyone so bent on incompatibilizing for the sake of incompatibilizing? It's one thing to drop baggage, but to adopt new fugly syntax just for making it incompatible to PHP 5.2? You do realize that 5.3 still hasn't reached 20% spread yet?

But this does indeed highlight a cargo cult programming deficiency with that project. PEAR1 is all PHP4, and the next version PHP5.3 only. But zilch in between. That's a clear case of policy circlejerking over working code. And an actual reason people avoid it like the plague.
And don't think they droped the single quotes enforcement in their coding standards yet (because it's faster, or whatever). Which is why I can't be bothered to try to send any patches.

[–]dshafik 1 point2 points ago

There is nothing inherently wrong with PHP 4 code, but you can built better, more efficient code with PHP 5.

PHP 5.2 is no longer officially supported, it was EOL'ed 18 months ago and hasn't had a release in over a year. Therefore targeting 5.3 makes complete sense. Where do you pull that 20% 5.3 adoption statistic?

Technically single quotes are faster (interpolation is slower, but it's not worth caring), but you are incorrect that the coding standards even dictate their usage, in fact the manual explicitly says otherwise.

[–]milki_ 1 point2 points ago

Okay, I lied. It has actually surpassed 20.4% by now: http://w3techs.com/technologies/details/pl-php/5/all
But anyway, that's of little consolation if you have to deploy code in the real world. Hencewhy I believe in PHP_Compat or upgradephp over syntax dependencies.

Anyway, I'll try to send in a patch to check if code baroqueness is still a requirement. Prepare for some bitching if the cited manual isn't true!

[–]dshafik 1 point2 points ago

I don't know how much I trust those statistics; they miss Facebook in their list of sites using PHP 5... that's quite a big (and obvious) one.

I'm well aware of real world usage, and even in higher education I see usage of PHP 5.3 (and higher ed is notorious for lagging behind on technology uptake!)

Good for you on that patch — if you get any hassle, send me a PM and I'll cite the manual on your behalf (I used to be a member of the first PEAR QA Team).

[–]tastur 2 points3 points ago

Try composer (Symfony folks use it).

[–]stefgosselin 0 points1 point ago

Yes, I have been wanting to look into this after reading a blog post on it. Looks promising.

[–]stonedoubt 0 points1 point ago

phpclasses.org is cool and been around for a long time

[–]milki_ 1 point2 points ago

Around for a long time is correct. But cool? That's not a common attribution.

The majority of code snippets there are abysmal. And the hoster is a dipshit. That's practically the only open source project repository that follows the subscribe-or-fuck-off model to push "newsletters", and then blames site defaults on the authors and users no less.

[–]stonedoubt 1 point2 points ago

I have never had too much a problem with the site... I am a subscriber, though.

I think it's easy to sit in judgement of others... show me a comparable site or project that you have built. It's not a team of people working on that site and it has been around long enough for me to have learned a lot about php from the thousands of free examples on the site.

I am now entering my 11th year as a php developer... I have been self employed for more than 8 years of that time. I am here all day with my wife and daughter and can see or hug them anytime I want. I typically earn more than double what I ever earned as a corporate developer with an MCSP. Sites like phpclasses.org and many others contributed to that success and I owe them respect rather than judgement.

[–]paranoidelephpant 1 point2 points ago

I never understood why there is so much hate for PEAR (not saying any is in this thread, but the community in general). It's a fairly solid package manager. Sure, some of the code available through it is crap, but there's lots of gold out there as well, especially in third-party repositories.

I favor a dual-distribution model for my code. I publish the source on GitHub and make "builds" available for download there. Each release also gets a PEAR package built and pushed to my own repository, also hosted on GitHub using Pages. That way my code is available as a tarball, or through a simple pear install mychannel/mypackage. I include full documentation and unit tests in both formats.

I use Pirum to manage my PEAR channel. It's very simple to use, and generates a flat-file static site which can be deployed anywhere.

As far as making your code easy to find, I do think that there is a real lack in this area for the PHP community. You can publish your package to the official PEAR repository, but unfortunately a lot of developers automatically associate code there with crap and don't use it anyway. PHPClasses is a pain to browse, and I've yet to find a useful bit of code there. I think your best bet is to publish it somewhere (GitHub or Google Code, and tag it on Ohloh) with the proper tags and let the search engines find it. Write a blog post or two about it as well. I find most of the third-party libraries I need through search.

[–]stephencorona 3 points4 points ago

I think PEAR channels are the best solution to the mess that is the official PEAR channel, but it's still a messy solution. Cross-channel dependencies are a cluster-fuck.

[–]krues8dr 0 points1 point ago

Everyone hates PEAR because most of the modules are bloated, poorly written, and fragile. THat's not to say all of them are, but the vast majority are. Sadly, because it could be a really great thing if anyone bother to do any oversight.

[–]ihsw 1 point2 points ago*

Edit: Sorry, I was referring to pecl packages. Disregard this comment.

[–]dshafik 0 points1 point ago

why are you compiling PHP code? Perhaps you mean PECL? I use pecl install successfully for about 99% of installs from PECL. And usually the culprit of any failure is system related, not the authors fault.

[–]philsturgeon 1 point2 points ago

I was just linked to this article by a friend, it looks like my recent article is basically an answer to all of your comments - without me knowing this was here:

http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php

Use of this site constitutes acceptance of our User Agreement and Privacy Policy. © 2012 reddit inc. All rights reserved.

REDDIT and the ALIEN Logo are registered trademarks of reddit inc.

π Rendered by PID 3403 on app-174 running 86c9e1d.