[dev] Components

[Gunnar Wrobel]

Zitat von Jan Schneider <jan at horde.org>:

> Zitat von Gunnar Wrobel <wrobel at horde.org>:
>
>>
>> Zitat von Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Gunnar Wrobel <wrobel at horde.org>:
>>>
>>>> Hi!
>>>>
>>>> With the following commit...
>>>>
>>>> Zitat von Gunnar Wrobel <p at rdus.de>:
>>>>
>>>>
>>>>>
>>>>> commit 5e98a19ff7e635c7c32b849f9663b205d09f2efa
>>>>> Author: Gunnar Wrobel <p at rdus.de>
>>>>> Date:   Wed Jan 12 12:05:45 2011 +0100
>>>>>
>>>>> Rough component documentation is possible now.
>>>>>
>>>>
>>>> .. you can now use the components package to generate HTML  
>>>> documentation for a single Horde component. Still pretty rough  
>>>> around the edges but you should be able to run it locally like  
>>>> this:
>>>>
>>>> php components/bin/horde-components -t components/data/html -O  
>>>> ../tmp framework/Exception
>>>>
>>>> This should generate the HTML pages for the "Exception" package  
>>>> into the ../tmp directory.
>>>>
>>>> The resulting pages are currently following the Routes draft at  
>>>> http://dev.horde.org/routes/
>>>>
>>>> Of course there is still a lot missing and these were the  
>>>> elements I was considering to include in the pages for each  
>>>> component:
>>>>
>>>>
>>>> - Name
>>>> - Summary
>>>> - Important bullet points  
>>>> (http://components.symfony-project.org/dependency-injection/)
>>>> - Description
>>>> - Changelog
>>>> - Last Release version
>>>> - Released versions + changes
>>>> - Dependencies
>>>> - Release Feed
>>>> - Download link
>>>> - Repo link
>>>> - Developers (www / mail)
>>>> - License
>>>> - Documentation
>>>> - Installation instructions
>>>> - Link to mailing list
>>>> - API doc
>>>> - Examples
>>>> - CI link / stats
>>>> - Horde backlink
>>>>
>>>> If you have any additional wishes/ideas or some remarks please  
>>>> let me know.
>>>>
>>>> In order for these component pages to make sense I think I need  
>>>> actual releases. A good first target might be the "Injector"  
>>>> package which seems to be rather stable to me.
>>>>
>>>> I did not think much about how to actually do component releases  
>>>> yet. I assume we could/should switch pear.horde.org to pirum  
>>>> (http://www.pirum-project.org/). This would reduce pear.horde.org  
>>>> to something like http://pear.pirum-project.org - The information  
>>>> that our current PEAR server displays on each package would then  
>>>> be replaced by the component information on  
>>>> http://components.horde.org. Pirum  
>>>> (https://github.com/fabpot/Pirum/blob/master/pirum) is rather  
>>>> lean and I assume we could tweak it in case necessary.
>>>>
>>>> Once http://pear.horde.org is ready for releases and contains the  
>>>> first Horde4 component release I would start on  
>>>> http://components.horde.org.
>>>
>>> I always thought that Pirum was *too* lean for our purposes, since  
>>> it required manual uploading of packages to the server's file  
>>> system last time I looked. This might have been changed by now, or  
>>> this might no longer be an issue if this is being automated with  
>>> components. I just wanted to raise my original concerns about Pirum.
>>
>> I admit I'm not aware of the exact requirements we have when it  
>> comes to releasing PEAR packages. The process didn't see much  
>> attention with Horde3. So we want to have uploading via HTTP? Do we  
>> really need that?
>
> Not necessarily, if we have some other comfortable way to upload  
> releases. scp'ing tarballs to the pirum server is too error prone  
> IMO though.
>
>> The process could also be automated with a system similar to what  
>> pearhub.org is providing though the effort for that might be higher.
>
> What exactly of pearhub do you mean (I didn't know it before you  
> mentioned it)? Automatic pulling of a package from a repo?

Yes, pearhub.org is generating the packages automatically. I did not  
dive into it yet but as far as I understood it the trigger is a  
repository tag. Which is kind of difficult in our case as we don't  
have a repository per package. It should be possible to switch to a  
different type of trigger though. Maybe a special file in the root  
directory of the package. Still it would be some effort to code that.

>
>> To be honest I can also live with the current pear.horde.org if we  
>> need some of the features provided by the current installation. It  
>> just seemed to be somewhat neglected.
>
> That's true but should be the rationale for choosing one instead of  
> the other. The key point for me is that releasing packages must be  
> easy. Uploading a package with a web form is easy. Using some  
> horde-components command line call is easy too.

Okay, then I'm tempted to choose the latter. I planned a release  
helper module for the components tool anyhow. Something that includes  
a few sanity checks for the package, bundles and uploads it. If you  
wouldn't like scp what would be the preferred way of doing it? FTP? Or  
would it be okay to rely on sftp as long as the command line for that  
is assembled automatically by the components tool?

How much do we care about security in the release process by the way?

A quick check suggested that only Pyrus is able to sign PEAR packages.  
But it is probably not even possible to validate this with the current  
PEAR default version so nobody would use that.

Another thing would be the access rights to the Pirum server - there  
are none. So this would only be restricted by the access controls for  
the upload path. Anyone that can upload could push anything /  
overwrite anything. I don't see that as problematic given our current  
status and it might never be a problem. I don't think we will open our  
PEAR channel to anyone but the devs that also have access right to  
git. But it probably wouldn't make much sense starting with Pirum now  
just to find out that we need more a month later.

If we go for Pirum I might still fork and tweak it. While working on  
the components tool I had a lot of "fun" - read "frustration" - with  
the basic PEAR code. I feel there is no way for a sane development  
based on the PEAR code structure as there is no functional internal  
API at all. I was hoping for PEAR2 or Pyrus and looked into that at  
the peak of my frustration. It might be somewhat cleaner but nothing  
that would help a lot. So I'm still considering extracting the  
Components_Pear_* part into Horde_Pear at some point. That could also  
be the backend for a Pirum fork then.

Cheers,

Gunnar

>
> Jan.
>
> -- 
> Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de