[dev] Horde framework package directory structure

[Jan Schneider]

Zitat von Chuck Hagenbuch <chuck at horde.org>:

> The questions are: doc vs. docs, lib vs. src, and test vs. tests. I
> have an aesthetic leaning towards doc, lib, test, which are consistent
> with ruby and python and have a great unix-y three-letter cleanliness
> to them. However, one could also make an argument for being consistent
> with PEAR2:
>
> http://wiki.pear.php.net/index.php/PEAR2_Standards#Directory_structure
>
> However, we can always bundle PEAR dependencies in our own structure,
> and advanced users can just put our lib directory and PEAR2's src
> directory both into the include_path (and I just don't like src - src
> is for compiled languages, it seems to me).

I'm really torn between those, and each time I think about it, I get  
to a different conclusion.

If we rearrange the directories anyway, we should chose the most  
logical structure, which is an argument for doc/lib/test.

Then again, I wonder if it is really a good idea to create our own  
structure, if there already is some kind of standard. It only makes it  
harder for developers from both worlds. And people who are used to  
PEAR2 would get into Horde much easier if we adopt their structure.

That being said, I don't think the PEAR structure is really that ugly.  
I don't know the discussion that resulted in this outcome, but looking  
at the directory names, I think they tried to get them as close as  
possible to the (already existing) file roles. "examples" isn't that  
inconsistent, because they also have "tests". And they probably would  
have "docs" if the file roles wasn't already called "doc". Looks like  
sticky, inconsistent legacy crap, but makes sense from their POV.
Regarding Eric's argument, "src" might makes sense because the files  
*are* processed. The PEAR2 packages are usually not supposed to be  
extracted as-is, but installed by Pyrus (the PEAR2 installer), which  
moves them to the final place, and even might process them further  
though install tasks.

If bundling is an argument, I don't really want to shuffle bundled  
PEAR files around to match our own structure. This is calling for  
trouble.

My conclusion for today is, that a clean, consistent structure would  
be nice to have, but adopting existing standards is going to help us  
more. But that might change tomorrow. ;-)

Jan.

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