[dev] Git splitting

[Michael M Slusarz]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>>
>>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>>
>>>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>>>
>>>>>> The next step will be to determine how we can use PHP composer  
>>>>>> to allow developers to assemble the disparate repos into a  
>>>>>> format that we can actually use on a day-to-day basis.  Should  
>>>>>> not be that difficult - we should only need to replace/alter  
>>>>>> the install scripts in framework/bin.
>>>>>
>>>>> OK.  Verified that we can create composer.json with his library:
>>>>>
>>>>> https://github.com/claylo/conductor
>>>>>
>>>>> On the command line, it works via:
>>>>>
>>>>> # php package2composer.php
>>>>>
>>>>> in the same directory as a package.xml file.  One caveat: this  
>>>>> needs to be added manually to the composer.json file:
>>>>>
>>>>> "repositories": [
>>>>>     {
>>>>>         "type": "pear",
>>>>>         "url": "http://pear.horde.org"
>>>>>     }
>>>>> ],
>>>>>
>>>>> (This can be done via a config file going forward).
>>>>>
>>>>> This will install all dependencies for a package using Composer  
>>>>> (using PEAR packages).
>>>>>
>>>>> It seems that Pirum does automatically create compose repos when  
>>>>> building the PEAR repo, so maybe we can take advantage of that  
>>>>> in the future.
>>>>
>>>> I'm still confused how this will help with people using our split  
>>>> git repositories. This will work against the released PEAR  
>>>> packages, right? So, how will we help people manage the various  
>>>> dependencies when using git? If I'm checking out git to get the  
>>>> latest and greatest code to work against (or help develop), I'm  
>>>> also going to want to be able to checkout the git repository of  
>>>> all of it's dependencies, not the PEAR packages - especially if  
>>>> we are in development of a new major version where we won't have  
>>>> any PEAR packages released yet that are compatible.
>>>
>>> Composer is capable of building packages from Git.
>>
>> This is besides the point anyway.  Above I am discussing how we can  
>> create composer.json files for all packages as an alternative to  
>> PEAR installation.  It has nothing to do with git reorganization.   
>> This is something that can be done TODAY.
>
> Maybe, but the point I was making, and Jan has addressed, is still  
> valid. Before we can split the repos, we need to ensure we can help  
> developers manage the dependencies while checking out any of our git  
> repositories. I guess the context of the email caused me to misread  
> the point you were making about composer if it did not have anything  
> to do with splitting the repos.

Yeah, this was what I was talking about in my first email.  Not sure  
if composer will be able to do this for us or not, or if we have to  
roll our own.  So I was looking into Composer in general and the idea  
of auto-creating composer.json files was an offshoot of that.

For the record, it looks like Composer can NOT do something like  
download all git repos that are dependencies.  It can install from a  
git repo, but the local copy is not a git repo - it's just a  
collection of files.

But that's fine.  And that's not really the point of of splitting the  
repos anyway.  Instead, the idea is that someone wants to fix  
something in Horde_Imap_Client they only have to download the  
Horde_Imap_Client repo and make the fix.  composer.json comes in handy  
if they want to run the unit tests for a particular package.  The  
latter makes it much more realistic that people who have no interest  
in Horde applications, but want to use some of the libraries, can use  
the code.

One of the major issues right now, as I see it, is that is is pretty  
much impossible for ordinary users to easily create patches.  We  
essentially require them to run a completely separate installation in  
order to do this.  By changing, we now dramatically lower the bar for  
development entry.  People can install and run their installations  
through the normal channels (i.e. PEAR), and then only need to  
download a tiny subset of Horde (i.e. Horde_Core) when they discover a  
bug.

Either way, I can't tell you how excited I am to have a split repo.   
Looking at the test repo I created, it is about 1,000x easier to track  
both the changes, tags, and branches for a particular component.  For  
me, large chunks of version 3 of Horde_Imap_Client have been written  
already, and switching to this kind of development will actually allow  
that code to see the light of day -- since it is completely impossible  
right now to do this with the current setup (creating a topic branch  
does NOT work for this kind of thing).

michael

___________________________________
Michael Slusarz [slusarz at horde.org]