[dev] Components

[Jan Schneider]

Zitat von Gunnar Wrobel <wrobel at horde.org>:

>
> 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?

The latter. As long as it's automated, scp/sftp/ftp is fine.

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

As much as we do for application releases today, I guess. Which means  
secure upload and locally generated hashes.

> 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.

Signing would be a bonus, though we can add that later when it makes  
more sense.

> 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.

Does this mean that Pirum doesn't support versioning? That would be a  
show stopper for me.
We don't have a protection against accidental overwriting at the  
moment either, beside regular backups. At least some chmod -w after  
the upload might make sense. (or would we need -w for the parent  
directory to disallow overwriting?)

> 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.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/