[dev] Split Git

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

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

We have a PEAR parser that programatically will give you the list of  
packages/channels you need to install given a single package.xml file?  
  I've spent hours looking for this, so this is fantastic news - where  
is it located?  (This underscores the need for us to keep all  
install-related code in a single location).

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

How does composer work with required binary extensions though?  If it  
doesn't provide that, this is a non-starter.

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

For development purposes, performance isn't the number one consideration.

And the current method is not ideal because it breaks (without manual  
intervention) anytime a framework library file is changed/added.

A better solution is probably to create an Autoloader ClassPathMapper  
that handles loading files from a development directory.

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

In terms of creating the script, config files are secondary to me and  
can be implemented after we get the basic script working with command  
line switches only.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]