[dev] Switching from PEAR to Composer

[Ralf Lang]

Hi Kieran,

Am 28.10.2020 um 19:58 schrieb Kieran Brahney:
> On Wed, 28 Oct 2020 at 14:44, Ralf Lang <lang at b1-systems.de> wrote:
>> Nice to hear from you.
> Thanks Ralf! I appreciate you taking the time to reply.
>
>> See https://horde-satis.maintaina.com/#horde/imap_client for a "pear
>> free" version using only composer for installation and composer format
>> dependencies. It's the git-master versions, possibly with up to 7 days
>> of delay in commits.
>> https://github.com/maintaina-com/imap_client
> It looks like you've done most of the work already! Is there anything
> stopping these being sent to the horde repositories, or anything left
> to do?

Mostly time constraints. I think there is an agreed-upon plan to
integrate this into horde/* master branch and then eventually release
tagged versions.

> RE: using the maintaina repositories. I have a couple of questions
> which I hope you don't mind answering:
> * There are a few branches; is dev-master the branch to use?

The master branch is ready to be consumed via composer. This is the
version currently required by anything in the "horde-deployment" repo
and in the dependency tree of all maintaina-packaged libraries.

The "maintaina-bare" branch is basically the horde/* master branch +
commits not yet upstreamed but without a fixed composer.json - this
avoids pull/merge issues when integrating features with the current
state of upstream horde. This is where I put new code first.

The "maintaina-composerfixed" branch runs the horde-components tool
against .horde.yml to generate dependencies against the maintaina satis
repo. In other words, its only purpose is to repackage code. The only
difference to the "master" branch is master also contains a warning text
file.

> * Are you using the repositories for anything else - I'm not going to
> find some maintaina specific code crop up?

There is no code for a specific installation involved. All code in these
maintaina-com/ repos is at least intended to be merged upstream.
However, this requires review and consent.

I run some software off this code, it's fairly stable for my use case. I
also provide some containers and ready-made deployments which in turn
run off this code.

> * It's good to hear it's regularly updated. Are you manually updating
> the forks or some automated process?

It's all github actions. I did it manually first, but then came up with
above concept which allows me to develop both merge-ready commits and a
run-ready state without too much overhead.

>> If you need the composer conversion for one of the tagged versions, I
>> can provide you with instructions on how to create that yourself.
> I'm just looking for the latest and greatest code heh. dev-master on
> your repositories sounds like it fits the bill. The only issue with
> lack of tags is when a commit to dev-master randomly brings CI to a
> halt.
If you hit for latest-greatest, then the satis repo is currently the
place to go.
> I believe for horde/imap_client it's a case of forking 16 horde
> repositories, and then updating composer.json? The problem is just the
> effort required to keep those 16 forks up to date.

Yes, that's why I automated that part. Anyway, I hope we can have the
libraries on packagist soon.

PS: I am currently trying out your fixes for composer2. It's really nice
once plugin version can support both major revisions.

Regards

Ralf

-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537