greetings
Brett Bieber
I'm just getting caught up with what you guys are working on and it
looks very interesting.
Have you guys looked into PEAR2 and what's going on there? There's a
bit of overlap, but great progress nonetheless. The goals we have are
very much the same, and I'm glad to have others that are thinking the
way we are. PEAR package distribution is the way to go. :-)
--
Brett Bieber
Alan Pinstein
I talked about PEAR2 and pyrus with the PEAR guys a couple of years
ago and they didn't seem at all interested in this idea. From what I
could tell pyrus seemed more like an internal re-write of stuff rather
than focusing on the end-user interfaces w/r/t ease-of-packaging and
ease-of-sharing.
I and the others that started this group with me are of the opinion
that the PHP and PEAR governing bodies were not focusing on technology
that accelerated the progress of the community as a whole.
The PEAR group seemed to want to focus on "code quality", bugging
people to fix bugs, and add docs, and manage a proposal infrastructure
for the community.
IMHO (and those of this group) none of those things are useful
"government" functions of PEAR. The community will decide which
projects are best by trying them and either using them or not. What
PEAR should be doing is reducing packaging and distribution friction
to 0. But like I said, no one on PEAR seemed to agree with this
sentiment.
Thus we started pearfarm to bring to the PHP community the advantages
of a frictionless code-sharing infrastructure.
If things have changed, I would like to hear more about your efforts
in those areas.
Thanks!
Alan
Brett Bieber
Great to hear from you.
On Wed, Dec 23, 2009 at 3:30 PM, Alan Pinstein <apin...@mac.com> wrote:
> I talked about PEAR2 and pyrus with the PEAR guys a couple of years ago and
> they didn't seem at all interested in this idea. From what I could tell
> pyrus seemed more like an internal re-write of stuff rather than focusing on
> the end-user interfaces w/r/t ease-of-packaging and ease-of-sharing.
>
> I and the others that started this group with me are of the opinion that the
> PHP and PEAR governing bodies were not focusing on technology that
> accelerated the progress of the community as a whole.
>
> The PEAR group seemed to want to focus on "code quality", bugging people to
> fix bugs, and add docs, and manage a proposal infrastructure for the
> community.
Interesting. I've only been on the PEAR group for the last 1.5 years,
so I can't speak to what happened back then. But yes, the PEAR Group
is more of an administrative body that guides the project rather than
the primary developers for the PEAR project, as it's grown to be quite
a large project.
As you probably know there are a few select people that understand and
improve and currently maintain the pear installation and distribution
infrastructure, and those would be the best people to talk to about
things like this - Greg Beaver, Helgi, and myself just to name a few.
> IMHO (and those of this group) none of those things are useful "government"
> functions of PEAR. The community will decide which projects are best by
> trying them and either using them or not. What PEAR should be doing is
> reducing packaging and distribution friction to 0. But like I said, no one
> on PEAR seemed to agree with this sentiment.
>
> Thus we started pearfarm to bring to the PHP community the advantages of a
> frictionless code-sharing infrastructure.
>
> If things have changed, I would like to hear more about your efforts in
> those areas.
Well the pear project has been moving along steadily for quite some
time. It thrives on contributions from the community that meet very
strict coding standards and practices, which is what the group
primarily oversees. A pepr proposal is a very good place to get code
viewed by other developers and into the main PEAR repository as you
probably know.
At any rate PEAR2 has quite a few changes in store for the PEAR
project, and some areas are still in flux. The largest obstacle to
PEAR2 was the 5.3.0 release because the PEAR2 standards use namespaces
and a lot of the new PHP features. Unfortunately the delays of PHP 5.3
put quite a bit on hold for a long time, but things are beginning to
pick up again now we 5.3 out and a clear direction to go.
The short of it is... pyrus/pear2 has a lot of great tools that we've
been working on for quite some time, some which may be of use to you,
and I'm sorry we haven't communicated the progress the PEAR project
has made with PEAR2 yet.
But! It looks like your group is interested in the PEAR installation
and distribution infrastructure as well, which is fantastic... and I'd
be happy to work with you guys and/or hear your suggestions on
improvements to the pear project and anything else related to pear
packages, channels and installers.
It is a good time to be a PHP developer. It definitely shows with all
the PEAR-related development that is going on. :-)
--
Brett Bieber
Alan Pinstein
> improve and currently maintain the pear installation and distribution
> infrastructure, and those would be the best people to talk to about
> things like this - Greg Beaver, Helgi, and myself just to name a few.
Helgi was at the lunch meeting :/ BTW looking back in my email the
conversation was only 1 year ago, at php|works Atlanta.
I even followed up with a very long email (which I've included at the
bottom) which didn't seem to generate a response or discussion.
>> If things have changed, I would like to hear more about your
>> efforts in
>> those areas.
>
> Well the pear project has been moving along steadily for quite some
> time. It thrives on contributions from the community that meet very
> strict coding standards and practices, which is what the group
> primarily oversees. A pepr proposal is a very good place to get code
> viewed by other developers and into the main PEAR repository as you
> probably know.
I do know, and I couldn't care less about getting code into the PEAR
repo. As explained previously, it's my opinion all of the friction
created by the PEAR process *harms* innovation. Friction is
antithetical to efficient progress. There are of course benefits to
such a process, but I am more of a bleeding-edge guy, so those trade-
offs don't work in my favor.
If someone has a useful lib and they want to share it, with PEAR it's
a weeks-long process of proposals, gatekeepers, edits, etc etc.
With pearfarm and 10 minutes of time, with no prior PEAR packaging
experience, you have packaged your lib via PEAR and made it available
to the world.
> At any rate PEAR2 has quite a few changes in store for the PEAR
> project, and some areas are still in flux. The largest obstacle to
> PEAR2 was the 5.3.0 release because the PEAR2 standards use namespaces
> and a lot of the new PHP features. Unfortunately the delays of PHP 5.3
> put quite a bit on hold for a long time, but things are beginning to
> pick up again now we 5.3 out and a clear direction to go.
5.3 is great and I am very excited about closure, LSB and circular GC,
but having a 5.3 req for pearfarm is just too high a hurdle at this
point in time.
Of course I have no problem with 5.3+ packages, but I want 5.2 ones as
well.
> The short of it is... pyrus/pear2 has a lot of great tools that we've
> been working on for quite some time, some which may be of use to you,
> and I'm sorry we haven't communicated the progress the PEAR project
> has made with PEAR2 yet.
>
> But! It looks like your group is interested in the PEAR installation
> and distribution infrastructure as well, which is fantastic... and I'd
> be happy to work with you guys and/or hear your suggestions on
> improvements to the pear project and anything else related to pear
> packages, channels and installers.
PEAR the cli app and API has obviously been a huge help to our project
and we have enjoyed using it. The package.xml docs are somewhat
lacking, but we managed to get through it.
There may be areas where we are not doing the right thing, or missing
an important feature, and it would be great to have your participation
to help us do things in the "PEAR way" w/r/t packaging.
However, I remain unconvinced that the PEAR board shares our
overriding philosophy, otherwise PEAR would've done this project years
ago. That's fine of course, but I think it means that there are only
limited ways for us to work together, at least for the time being.
We definitely welcome your participation and ideas, though!
Your experience working with PEAR would likely be invaluable to us. I
am sure you guys have already spent lots time thinking about many of
the issues we will face. For instance you've already pointed out the
Console_CommandLine project which looks promising.
Also in regards to security it looks like there might be some signing
support in PEAR, if you could tell us more about that and how we might
use it best that would be great.
Fortunately we have an active community and some excitement around the
project and we will probably continue on our own for a while. The
project is young and fast-moving and I would like it to stay that way
for a while to see where it goes.
Regards,
Alan
-------------------------------------
ORIGINAL EMAIL TO HELGI FROM NOV 2008
-------------------------------------
I decided to attend Helgi Thorbjoernsson's PEAR talk at php|works '08,
entitled "PEAR2 & Pyrus, the Look Ahead". As a PHP user for over 10
years, I have of course long used PEAR to find good libraries; I have
contributed to the project by reporting bugs, posting patches and even
code for new projects. I also use PEAR to package my own open-source
php framework, phocoa. So I was quite interested in seeing what is the
future of PEAR as discussed by one of its leaders.
Pyrus, which is a new name for the "installer" part of the PEAR
project, looks really promising. Creating and hosting PEAR packages
just isn't easy enough at present, so the ideas behind pyrus are
important to modernizing the pear package manager project.
The other part of the talk was a more general discussion of the PEAR
project itself; how the community is structured, what the actual goal
of PEAR is, and some future ideas they have for pushing the PEAR
project forward.
For me, this is where the alarms started going off in my head.
In addition to being a professional programmer, I also have a strong
business background. I don't really like to talk about myself, but I
think it's at least important for people to know by background a
little bit to understand where I am coming from with the comments I am
about to share. I have started 3 software companies (all product
companies, not consulting) and have worked as a Product Manager
several other startups and established software companies as well. I
built the entire Product Management process at the dotcom I worked at.
I have a business degree, and I pursue enlightenment in business
knowledge with the same passion that I seek the same in the world of
software engineering.
That said, here are some observations I had while in that session:
- I can't figure out what PEAR is as a community; what is the *value*
that PEAR is trying to provide for PHP developers. PEAR no longer has
a brand identity.
- There seems to be a lot of effort into solving the problem of
deciding which packages are official "PEAR" packages, how new packages
are selected, who helps maintain them, etc. I couldn't help but think
"who cares"? I just don't see the value proposition of PEAR having an
"official" set of packages that supposedly have "high quality" because
they've been "accepted" into PEAR. First of all, I think that the
"high-quality" message of the PEAR brand doesn't exist anymore,
because a) I use a lot of PEAR packages and they aren't all that solid
anymore, or well-documented, or easy to use, and b) I use PEAR to
manage other packages through the channel mechanism, and since anyone
can do that, clearly just because something is available via PEAR
doesn't mean it's quality.
- A lot of the proposed ideas did not seem scalable. It seemed that
the PEAR community was trying to do things for *other* people's
packages; on top of that, they report that it's hard to get people
involved to do these things. Thus, doing more of this only makes the
problem worse.
- The organizational structure of PEAR seems to be headed towards
a more hierarchical one, via the addition of "collectives" of people
that will oversee subsets of packages.
- There was a lot of talk about PEAR community members actively
inserting themselves into projects that they didn't actively create,
or even have an interest in; to search for bugs in those packages,
review APIs, etc.
- Helgi pointed out overhearing once "Didn't PEAR die 2 years ago"?
And that the community's solution to this was press releases of
"packages" of software, kind of like Zend Framework does.
So, in summary, it seemed to me that 1) PEAR's brand is suffering, 2)
PEAR is lacking for a strategic vision, 3) many of their proposed
processes and ideas would actually further dilute that vision, and 4)
many of the proposed process tweaks to "fix" things actually had
structural faults that would make them unscalable for an open-source
project.
I sat down at lunch with Helgi and former PEAR member Paul Jones along
with several others to discuss this.
First of all, let me state that my point in this is not for me to
promote specific ideas as to where PEAR should go. I have some, of
course, but frankly I don't have time to become involved in another
project right now, and I don't want to be "that guy" that just flames
a project about what it should do. Nobody likes that guy, and for good
reason.
Instead, out of pure concern for the greater good of the community, I
simply want to raise some questions, and hopefully push the PEAR
community into a bout of self-examination. Based on my observations,
PEAR is stuck in a rut, and I am simply suggesting a process needs to
be undertaken; I have faith that the results of that process, without
my involvement or ideas, will be better for the future of the project
than the current status-quo.
At the lunch table, the first question I asked was, "Give me PEAR's
elevator pitch. What is it that PEAR does, why, and how." There wasn't
a good answer. This actually isn't atypical at all of an organization
that's been around a long time, so it isn't really surprising, or even
a "bad sign". These things can be correctly very easily, especially
when there is a team of smart & dedicated people available to have the
conversation.
So, what is that process? Essentially, it's a step-back to the 30,000
foot view to talk about strategy. My absolute favorite article on
strategy is "What is Strategy?" by Michael Porter (attached). You
should read it, it's great.
The super-short summary of that article is:
- Strategy is choosing where you want to go
- Picking a direction involves trade-offs; you can't do everything
- Thus, pick things that reinforce each other
- Then, implement activities that push you down the road in the
direction you want to go
- A clear strategy means it's obvious for any given "idea" whether
that idea is aligned with strategy or not. Only do things that are
aligned with your strategy. It's amazing how easy it is deciding what
to do one you have a strategy. It's actually very liberating.
Even for an existing organization, this is a great process to go
through. Once you're done, then you can ask yourself, of all then
things that I am doing now (because that's what we've always done),
does it makes sense to keep doing it? Should we stop that activity
altogether, or just approach it differently? It is a long-term
process; it needs to be done only once every 1-2 years. A good
strategy, even under review, can end up nearly unchanged for decades.
We review our strategy every year at my companies.
So that was basically my point. I then walked through what PEAR does
now, and asked why. It seemed that the main things PEAR does now are:
1) Assemble a collection of packages that are "high quality", and
provide infrastructure for managing those projects
2) Produce a package manager
3) Maintain coding standards that hopefully the entire php community
uses
PEAR as a collection of packages is an interesting idea. It was very
important 10 years ago, when it wasn't easy to find PHP libraries.
However, that isn't really a problem anymore. I challenged this
activity as the source of some of PEAR's problems:
- PEAR packages aren't really related, like in Zend Framework. ZF got
a lot of steam because it represents a "best practice" for doing
things. Your choices are made for you regarding DB access, templates,
etc.
- PEAR can have MULTIPLE packages that solve the same problem. This
reinforces the perception above.
- Thus, a "release" of PEAR packages is largely meaningless, since the
collection of those packages doesn't have any more significance than
an individual package.
The idea that PEAR wants to help establish quality packages is
obviously a useful and commendable goal. I just think it's going about
it the wrong way.
The current infrastructure for helping maintain quality seems to me
antithetical to how open source should work. Open-source, at its best,
is people building and releasing code that solves problems, and the
best solutions (combination of code and marketing) end up getting
traction in the marketplace. Those that attract more attention get
more help, and thus improve faster. This system works. The more
transparent you make information, the faster and better this process
works.
The way PEAR does it, the community has to get involved in each
project even though they may not really care about it; that doesn't
scale, and it doesn't produce ideal results.
I think PEAR should seriously reconsider its "collection of packages"
idea. The collection isn't a "full stack", and it isn't a "best of
breed" like distros are. The collection of packages, the way they are
done now, has no more utility than any individual packages. Since PHP5
essentially requires all packages to be re-done anyway, I think that
it's a perfect opportunity to abandon the idea of a "PEAR project" in
favor of another approach that is more aligned with your desired
strategy.
One concrete recommendation I have for PEAR is to stop "managing"
quality, and provide the tools for quality to emerge. There were some
good ideas regarding Code Sniffing to score standards conformance, and
already there is infrastructure for tracking project activity,
outstanding bugs, etc. The simple tweak of making these useful metrics
transparent will accelerate the community's ability to detect good
projects vs bad ones. For reference, look at things like sourceforge
and github.
A side effect of PEAR wanting to have good packages I think is to try
to get php developers to be able to find "good" packages. PEAR already
has a huge megaphone; it makes sense to continue to be able to push
attention to good projects (and new ones as well). Look at the Apple
App Store; think about what that ecosystem did for mobile development
and how maybe PEAR could take lessons from that.
The other concrete idea that was tossed around regarding code quality
is that of PEAR having a "Quality Seal". Packages with a quality seal
would get the most marketing support, and would be determined by
having a set of qualifications for a package to receive the seal. This
idea is borrowed from Palm OS; they used to have a "Palm Quality
Certified" program of some kind. To pass, your program had to meet
certain criteria, and as a developer, you submitted your app to a
third-party which would test it and you would either PASS or FAIL. The
criteria were well-known; you could self-test before sending it in.
Just by "going for certification" your project got a lot better,
regardless of whether you actually went through with it and PASSed.
I would imagine such a program for PEAR would have criteria like:
1) Project is pyrus-installable.
2) Project has API docs.
3) Project has User Guide.
4) Project has Unit Tests (with coverage > X%)
5) Project has license X or Y or Z.
6) Project has publicly accessible SVN/GIT/etc
7) Project has web site with bug reporting infrastructure, support
mechanism (either email and/or forum etc)
8) A reasonable 3rd party can install and trivially use the package
without any errors by following the docs.
etc etc
I for one would certainly favor the use of such PEAR-certified
packages. It is also a great thing for the community to do; it's easy
to test qualifications without having to know the code, or get
involved in the project. Lots of people would go for it due to the
exclusivity and marketing attention that they would get.
Plus, if PEAR provided infrastructure to help all projects do this,
think of the impact that it would have on the consistency and overall
code quality of code produced by the entire php community. It could
literally change the face of php package development for the next 10
years.
I also think that pyrus is great; I would rather see effort go into
further improving the packaging system for php to make it easier to
use as a consumer; easier to use as a developer of packages, etc.
In conclusion, I hope that you take my observations at face value; I
have no ulterior motive. I only share my observations because I do
think that if you maintain the current track, PEAR will fall further
into the dustbin of being a dead project, and that'd be a shame. As a
top-level PHP project, you have awesome opportunity to make a huge
difference, you should make the most of it.
Respectfully,
Alan Pinstein
apin...@mac.com
Twitter: apinstein
http://phocoa.com [phocoa php framework]
Brett Bieber
Helgi was at the lunch meeting :/ BTW looking back in my email the conversation was only 1 year ago, at php|works Atlanta.As you probably know there are a few select people that understand and
improve and currently maintain the pear installation and distribution
infrastructure, and those would be the best people to talk to about
things like this - Greg Beaver, Helgi, and myself just to name a few.
I even followed up with a very long email (which I've included at the bottom) which didn't seem to generate a response or discussion.
If things have changed, I would like to hear more about your efforts in
those areas.
Well the pear project has been moving along steadily for quite some
time. It thrives on contributions from the community that meet very
strict coding standards and practices, which is what the group
primarily oversees. A pepr proposal is a very good place to get code
viewed by other developers and into the main PEAR repository as you
probably know.
I do know, and I couldn't care less about getting code into the PEAR repo. As explained previously, it's my opinion all of the friction created by the PEAR process *harms* innovation. Friction is antithetical to efficient progress. There are of course benefits to such a process, but I am more of a bleeding-edge guy, so those trade-offs don't work in my favor.
If someone has a useful lib and they want to share it, with PEAR it's a weeks-long process of proposals, gatekeepers, edits, etc etc.
With pearfarm and 10 minutes of time, with no prior PEAR packaging experience, you have packaged your lib via PEAR and made it available to the world.
Understood. I do recognize the goal of your channel is different than that of the (current) PEAR project in terms of what we provide.
My main point is by relying on the PEAR installer you're inherently tied to the development of 1. the pear installer, 2. the package.xml format, and 3. the PEAR channel protocols; Which makes it important to work together where possible or at least communicate to each other especially with the development of REST1.4, 1.5, new channel protocols, the new pear package format, package.xml v2.1, the pyrus installer, and many other things.
With that said, a stable library for parsing the channel files, package.xml, and communicating with PEAR channels could be a very important thing to have with so many projects relying on that infrastructure for the distribution of their software.
:-)
Wow, this is epic! This may take some time for me to look through, but thanks for forwarding it as I'm certain the current PEAR group hasn't seen this.
Thanks Alan,
--
Brett Bieber
Alan Pinstein
Pearfarm is now up and running on the live site at:
I was hoping you'd be able to help us out with a few things:
1) We are looking for people to give pearfarm.spec a good workout, do
you know people that could try to package their software via Pearfarm/
pearfarm.spec?
2) We are trying to pre-seed the repository with some useful/popular
packages, so we'd be interested in getting some high-profile packages
on pearfarm. Packages that don't "fit" in official PEAR, such as those
on this page, http://pear.php.net/channels/, would be ideal.
3) Would it be appropriate to list Pearfarm on that page as well? http://pear.php.net/channels/
Thanks in advance.
Regards,
Alan
Brett Bieber
> Hi Brett-
>
> Pearfarm is now up and running on the live site at:
>
> http://www.pearfarm.org
Yes, I've been following what's going on and it looks like things are
coming along nicely.
Are you still not considering contributing any of the work you've done
back to the PEAR project, for either PEAR2/Pyrus? :-)
The reason I ask is, PEAR2 allows anyone access to work within the
sandbox, and the new versioning standards eliminate the strict
stability and BC requirements. So the gemcutter model you're trying to
achieve will likely be possible on pear.php.net in the future if the
changes Helgi and I are proposing go through.
> I was hoping you'd be able to help us out with a few things:
>
> 1) We are looking for people to give pearfarm.spec a good workout, do you
> know people that could try to package their software via
> Pearfarm/pearfarm.spec?
Hmm... I'm not sure who you could contact. Generating the package.xml
is likely a pain almost anyone not using PFM or pyrus is running into,
so I suspect there are quite a few that could benefit. As far as
giving it a good workout, you could try packaging up Pyrus or PEAR —
those packages in particular use just about every feature of
package.xml and would be good candidates.
> 2) We are trying to pre-seed the repository with some useful/popular
> packages, so we'd be interested in getting some high-profile packages on
> pearfarm. Packages that don't "fit" in official PEAR, such as those on this
> page, http://pear.php.net/channels/, would be ideal.
Your best bet would be to contact the maintainers of those channels I
suppose. Some monitor the pear-dev list but most have separate
communication channels.
You could also look around for people using URI released packages. The
gemcutter model would be a good fit for people already using URI
releases.
> 3) Would it be appropriate to list Pearfarm on that page as well?
> http://pear.php.net/channels/
We can certainly add it.
Would a disclaimer somewhere be appropriate on pearfarm to indicate
that it is not associated with the PEAR project? Just a thought.
> Thanks in advance.
>
> Regards,
> Alan
--
Brett Bieber
Alan Pinstein
> back to the PEAR project, for either PEAR2/Pyrus? :-)
Well, the code will probably be licensed in some MIT/BSD style
license. Other than that, I still think that the previous thoughts I
posted govern our thinking right now. I think the project is too fast-
moving to fit well in the PEAR process at the moment.
> The reason I ask is, PEAR2 allows anyone access to work within the
> sandbox, and the new versioning standards eliminate the strict
> stability and BC requirements. So the gemcutter model you're trying to
> achieve will likely be possible on pear.php.net in the future if the
> changes Helgi and I are proposing go through.
Do you have a link to explain more on your proposals? It's kind of
hard for me to evaluate your ideas and roadmap.
The pear2.php.net site seems sparse, and I am not really seeing anyone
do anything with PEAR2/pyrus yet. I don't see any benefits that would
be gained by integrating the projects, other than to add overhead of
supporting more stuff. There aren't even enough docs out there for me
to see how pyrus packaging (I don't really know how you're labeling
the new package.xml) would benefit us. Frankly the old pear might have
rough edges, but they haven't seemed problematic to us yet.
If you have any links/docs/blog posts that explain the benefits of the
new stuff, that'd be great.
>> I was hoping you'd be able to help us out with a few things:
>>
>> 1) We are looking for people to give pearfarm.spec a good workout,
>> do you
>> know people that could try to package their software via
>> Pearfarm/pearfarm.spec?
>
> Hmm... I'm not sure who you could contact. Generating the package.xml
> is likely a pain almost anyone not using PFM or pyrus is running into,
> so I suspect there are quite a few that could benefit. As far as
> giving it a good workout, you could try packaging up Pyrus or PEAR —
> those packages in particular use just about every feature of
> package.xml and would be good candidates.
What is PFM?
Frankly seeing the way pyrus executables have to be called, I don't
see them taking off anytime soon. I really like how PEAR allows you to
install executables that are in the $PATH. This is extremely valuable.
>> 2) We are trying to pre-seed the repository with some useful/popular
>> packages, so we'd be interested in getting some high-profile
>> packages on
>> pearfarm. Packages that don't "fit" in official PEAR, such as those
>> on this
>> page, http://pear.php.net/channels/, would be ideal.
>
> Your best bet would be to contact the maintainers of those channels I
> suppose. Some monitor the pear-dev list but most have separate
> communication channels.
>
> You could also look around for people using URI released packages. The
> gemcutter model would be a good fit for people already using URI
> releases.
Ok, we will do that. Thanks for the tips.
>
>> 3) Would it be appropriate to list Pearfarm on that page as well?
>> http://pear.php.net/channels/
>
> We can certainly add it.
Great, thanks! Go for it.
> Would a disclaimer somewhere be appropriate on pearfarm to indicate
> that it is not associated with the PEAR project? Just a thought.
That's fine, since we did use the PEAR name, it makes sense to explain
the relationship between the two.
Alan
Brett Bieber
Are you still not considering contributing any of the work you've done
back to the PEAR project, for either PEAR2/Pyrus? :-)
Well, the code will probably be licensed in some MIT/BSD style license. Other than that, I still think that the previous thoughts I posted govern our thinking right now. I think the project is too fast-moving to fit well in the PEAR process at the moment.
This is interesting as PEAR doesn't control the speed at which developers develop, merely a couple things - good coding practices and what happens after they say "This package is stable and I'm not going to change the API." So, to me, your comments highlight a mis-understanding about what PEAR is/does, and means we (PEAR) need to work on a lot of things — your previous suggestions sent to Helgi provide good insight into ways to improve this, and some of these the PEAR Group is already working towards.
I'd really like to hear some more of your suggestions, and also, solicit your help in improving PEAR. If the speed or coding standards restrictions are things you don't like, please help change it. Talented developers the likes of yourselves are exactly what PEAR is meant to represent.
Do you have a link to explain more on your proposals? It's kind of hard for me to evaluate your ideas and roadmap.
The reason I ask is, PEAR2 allows anyone access to work within the
sandbox, and the new versioning standards eliminate the strict
stability and BC requirements. So the gemcutter model you're trying to
achieve will likely be possible on pear.php.net in the future if the
changes Helgi and I are proposing go through.
Sure, the PEAR2 standards are here:
http://wiki.php.net/pear/rfc/pear2_standards
and the policies are here:
http://wiki.php.net/pear/rfc/pear2_policy
Note the sandbox information which allows anyone to release code. The collectives are meant to coordinate how similar packages function... so that if a user has invested time into understanding a CSS validator package, the HTML validator should function in a similar fashion for example.
The versioning standard modifications are here:
http://wiki.php.net/pear/rfc/pear2_versioning_standard_revision
And I'll copy this from another message summarizing what Helgi and I are working on ----
To summarize, this is two changes:
* Approving the pear2 versioning standard revision rfc
http://wiki.php.net/pear/rfc/pear2_versioning_standard_revision
* Allowing pear packages to use the pear2 standards, with minor
modifications like the vendor namespace prefix.
The second one is a huge discussion all in itself so it may be best to
break this up into separate discussions, but I'll try and summarize
here.
Both these changes could mean BC could be broken in an existing PEAR
package by changing the API version, WITHOUT requiring a new package
name.
So under the old system HTTP_Request becomes HTTP_Request2... under
this yet-to-be-written proposal by allowing PEAR(1) packages to use
the new standards, the API version and package version number could be
incremented allowing BC breaks.
To allow this, the installer would need to understand the proposed
pear2 versioning standards (paranoia, no api-breaks on upgrades, etc
which is how pyrus handles things currently). The idea is to get this
versioning standard approved for pear2 packages, then make a few minor
modifications to the pear2 standards with the goal of allowing PEAR(1)
packages to use the new standards for their releases.
Eventually this would mean there is no need for pear2.php.net, because
all the packages can be released on pear.php.net. Packages would just
need to set Pyrus as the required installer (this is done through the
<pearinstaller> tag in package.xml).
----
end of the copied message.
If we can get this approved and work out all the details, I think the gemcutter model would work great for pear and packages within the sandbox. I'd also like the push command to be represented in a standard format for and pear channel to use, as previously discussed, which means documenting it a little more, defining how to announce it and putting it into channel server software that anyone can use.
The pear2.php.net site seems sparse, and I am not really seeing anyone do anything with PEAR2/pyrus yet. I don't see any benefits that would be gained by integrating the projects, other than to add overhead of supporting more stuff. There aren't even enough docs out there for me to see how pyrus packaging (I don't really know how you're labeling the new package.xml) would benefit us.
There are quite a few docs in the PEAR manual - http://pear.php.net/manual/en/pyrus.commands.php
Specifically the make command functions like the .spec file you've developed, only assumes a standard package layout.
http://pear.php.net/manual/en/pyrus.commands.make.php
And the package command:
http://pear.php.net/manual/en/pyrus.commands.package.php
Frankly the old pear might have rough edges, but they haven't seemed problematic to us yet.
That's good.
If you have any links/docs/blog posts that explain the benefits of the new stuff, that'd be great.
What is PFM?I was hoping you'd be able to help us out with a few things:
1) We are looking for people to give pearfarm.spec a good workout, do you
know people that could try to package their software via
Pearfarm/pearfarm.spec?
Hmm... I'm not sure who you could contact. Generating the package.xml
is likely a pain almost anyone not using PFM or pyrus is running into,
so I suspect there are quite a few that could benefit. As far as
giving it a good workout, you could try packaging up Pyrus or PEAR —
those packages in particular use just about every feature of
package.xml and would be good candidates.
PackageFileManager(2)
Frankly seeing the way pyrus executables have to be called, I don't see them taking off anytime soon. I really like how PEAR allows you to install executables that are in the $PATH. This is extremely valuable.
This is included in pyrus, just like pear. The PEAR2_SimpleChannelServer package installs a pearscs command to build pear channels with.
Ok, we will do that. Thanks for the tips.
2) We are trying to pre-seed the repository with some useful/popular
packages, so we'd be interested in getting some high-profile packages on
pearfarm. Packages that don't "fit" in official PEAR, such as those on this
page, http://pear.php.net/channels/, would be ideal.
Your best bet would be to contact the maintainers of those channels I
suppose. Some monitor the pear-dev list but most have separate
communication channels.
You could also look around for people using URI released packages. The
gemcutter model would be a good fit for people already using URI
releases.
Great, thanks! Go for it.
3) Would it be appropriate to list Pearfarm on that page as well?
http://pear.php.net/channels/
We can certainly add it.
That's fine, since we did use the PEAR name, it makes sense to explain the relationship between the two.
Would a disclaimer somewhere be appropriate on pearfarm to indicate
that it is not associated with the PEAR project? Just a thought.
Alan
Thanks for your comments Alan, I really do appreciate them.
--
Brett Bieber
Scott Davis
does enforce a standard on the developers. rubygems has no such
standard and look how successful it has become yes there are some bad
gems out there but its up to the developer to present good code and
let the community drive the quality and popularity the whole approval
thing was just a huge turn off for me until alan told me about this
idea. which in essence makes this like ruby gems.
I was also curious to why the pear client needs to be rewritten it
seems to function for the intended purposes just fine sure its a bit
verbose but I see pyrus as just another attempt to reinvent the wheel.
Unless im missing something huge. The PEAR project needs to focus on
the users and not the system. Since code reusability seems to be a
huge problem in the php developer community which i blame that on the
fact that there is no real community other then the php mailing lists
which tend to be very unhelpful because everyone thinks there way is
best.
PHP is a great and very fast language. Its still a bull in the web
laungages world but if something isn't done to unite the developer
community and im not talking about the core team im talking about joe
blow the freelance developer that is tired of rolling his own whatever
everytime instead of having a nice place to go search for something
that may fit his needs. This is the reason why rubygems is so
successful as a code community. sure PEAR is nice as a core place for
stable tested and approved code thats fantastic but shouldn't the
people using the code be the ones to judge? and thats what our main
goal with pearfarm lets the community drive the project.
Im im over the line here please tell me what im missing but as i see
it making a "PEAR2" will not solve this problem since PEAR already is
plagued by a bad rep. Fix the rep before you try and reinvent the
wheel.
Look what gemcutter did they started a revolution and now rubyforge
and gemcutter are one product. because rubyforge realized what
gemcutter provided was a community tool. PEAR as a project doesn't
have the reputation as being a community tool so we created the one.
Alan Pinstein
This is interesting as PEAR doesn't control the speed at which developers develop
, merely a couple things - good coding practices and what happens after they say "This package is stable and I'm not going to change the API." So, to me, your comments highlight a mis-understanding about what PEAR is/does, and means we (PEAR) need to work on a lot of things — your previous suggestions sent to Helgi provide good insight into ways to improve this, and some of these the PEAR Group is already working towards.
I'd really like to hear some more of your suggestions, and also, solicit your help in improving PEAR. If the speed or coding standards restrictions are things you don't like, please help change it. Talented developers the likes of yourselves are exactly what PEAR is meant to represent.
Note the sandbox information which allows anyone to release code. The collectives are meant to coordinate how similar packages function... so that if a user has invested time into understanding a CSS validator package, the HTML validator should function in a similar fashion for example.
For proof-of-concept packages, they should
The versioning standard modifications are here:
http://wiki.php.net/pear/rfc/pear2_versioning_standard_revision
If we can get this approved and work out all the details, I think the gemcutter model would work great for pear and packages within the sandbox. I'd also like the push command to be represented in a standard format for and pear channel to use, as previously discussed, which means documenting it a little more, defining how to announce it and putting it into channel server software that anyone can use.