[dev] Split Git

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> - Installation of code from git repos can be facilitated by a script.
>>> - This script can create/clone the git repos as needed.
>>
>> And update, and diff, and commit, and probably all the major git  
>> stuff. Wait, why did I argument against sub-tree again? :)
>>
>> Some extra sugar would be if you could checkout one repo, and have  
>> all dependent packages' repos checked out too.
>
> This would be great... although I think this will require digging  
> into PEAR code in order to grab the required dependencies (I really  
> don't want to be writing PEAR parsing code at this stage).

We already have a PEAR parser.

> I'm assuming we will be keeping the canonical package  
> dependencies/metadata stored in package.xml, since package.xml ->  
> composer.json generation is lossless while the reverse would be lossy.

Which means that we could use composer for this dependency pulling,  
which may be easier to implement.

>>> - All repos will be stored in a base folder
>>> - Option to create a separate, web-accessible directory.
>>
>> Not sure what you mean. Some like what install_dev does today?
>
> Yes.  Necessary since repo organization does not line up with our web layout.
>
> An optimization to the current system: we should not create symlinks  
> to framework libs under horde/lib - it probably makes more sense to  
> simply add an (admittedly long) list of include directories to an  
> ini_set('include_path') call in horde.local.php.

That's a viable alternative, though I'm not sure why you would  
consider this an optimization. I'd rather expect a long include_path  
to perform badly.

>>> - We combine all installation code that currently exists into a  
>>> single script.
>>> - Includes installation script described above.
>>> - Includes stuff in framework/bin
>>> - Includes stuff in horde-support/maintenance-tools
>>> - Includes the groupware install code (in fact, the  
>>> Horde_Core_Bundle code is probably a good place to start in terms  
>>> of creating the install script).
>>> - This script can be packaged via PHAR
>>> - Benefit: development install script work can be leveraged to  
>>> make end-user installs better also.
>>> - From a technical perspective: the goal would be to create test  
>>> installations and a developer installation using Vagrant where the  
>>> provisioning file contains nothing but 'horde-install' commands.
>>
>> Initially I was like "why mix and match end user and developer  
>> needs?", but you slowly convince me on that.
>
> #1: We either hide development options in documentation by default,  
> or make it less prominent than regular install.
> #2: I'm not sure how much #1 is even necessary, since most people  
> are just going to copy/paste whatever command-line string we give  
> them anyway.

Yes, exactly, I don't see any need to hide anything. We should of  
course carefully pick defaults, so that the majority of people don't  
have to enter lots of command line arguments. For others, including us  
developers, there should be an optional configuration file that  
replaces command line argument for certain checkouts.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject