Composer installation

[tomcastleman]

Hi @domibarton

Great work on this lib.. Any chance you could make this available as a package via Composer? You can do this here.

Looks like @rsimiciuc forked your repo 3 months ago and added Composer support but his fork is now stale and anyway it is better if your original package was added to Packagist rather than a fork. This way this great lib can be installed and kept up to date more easily!

If you need some help I can create a PR with composer.json - you will then just need to follow the instructions here. Once you have added Composer support @rsimiciuc should then delete his fork from Packagist.

Thanks!

[tomcastleman]

As a postscript. My suggestion to install via Composer would obviously relate to the pre-built classes in build. You could have a tag (or separate namespace or classname) for each version (2.2 and 2.4).

Thanks.

[rsimiciuc]

Cool, just let me know when you integrate composer with the main lib and I will delete my fork from packagist

[domibarton]

I just created a composer.json in the master branch and pointed it to the build/ directory. Though the built classes will rely in build/{version}/, so I created 2 separate branches 2.2 and 2.4.

But packagist only allows me to publish the package from the default github branch.

@tomcastleman Any ideas? Is there a way to install all versions under build/ via composer and load it via a specific namespace?

[tomcastleman]

There are a few ways of allowing users to select between 2.2 and 2.4, the most obvious I can see are:

• keeping each build version in its own namespace within master branch, or
• add tagged version for each build branch

Using namespaces

I would probably use this option. This would just keep your master branch only, and rename and namespace your build classes to follow psr-0.

This involves renaming the directory names, class file names. Eg:

• build/22/ZabbixApi.php:

namespace ZabbixApi\22;
class ZabbixApi {

You're on the way with this approach, if you need I can test and submit a PR.

To use the build classes one would then just need to:

composer require php-zabbix-api/php-zabbix-api:dev-master

And to use within their app:

use ZabbixApi\22\ZabbixApi;
// or use ZabbixApi\24\ZabbixApi;

$z = new ZabbixApi();

Using git tags

I think this option is overcomplicated for this purpose. But firstly you would ensure that the 2.2 and 2.4 branches only have the respective versions of the build classes contained within build directory, namespaced accordingly to PSR-0. For example:

build/ZabbixApi.php

Referencing the respective branches you have created, add a git tag for each. For example:

git checkout 2.2 && git tag -a -m 2.2
git checkout 2.4 && git tag -a -m 2.4

If you have linked up your repo with the packagist / github webhooks then this will automatically update on packagist and allow versions to be specified with composer:

composer require php-zabbix-api/php-zabbix-api:2.2 or

composer require php-zabbix-api/php-zabbix-api:2.4

[domibarton]

Thank you for your reply.
Sorry I don't know composer at all (more into Python for some time now ^^).

I'll created 2 separate branches (2.2 / 2.4) and I'll tag these branches properly.

I'll also remove the build/ directory from the master tree, and add the built classes to the build/ directory in the branches. Then I'll tag all branches properly, so that composer users can select their version via composer require as you already mentioned.

IMHO this is a proper release cycle 😄 , even when it's a bit more work to do.

Thanks for the webhook hint, I'll check it out.

[domibarton]

just created the tags (v2.2.0 & v2.4.0), so now we've proper release cycles 😤

@tomcastleman can you review the new tags?
@rsimiciuc can you delete your fork from packagist?

[tomcastleman]

@domibarton that's great to have proper semver with the releases. This is certainly the proper way of doing it.

I haven't tested yet but having glanced at the code I think you still need to rename the build class files and add a namespace to make it fully PSR-0 compatible, eg:

build/ZabbixApi.php

<?php
namespace ZabbixApi;

class ZabbixApi {

[rsimiciuc]

package deleted from packagist

[domibarton]

@rsimiciuc thanks!

@tomcastleman I've created the packages against the branches, can you test it?

2.2.x-dev
2.4.x-dev

If everything works fine, I will create the tags.

[tomcastleman]

@domibarton yes it seems to work fine. Thanks for doing this.

My only comment is the extra 'b' in the vendor name:

{
    "name": "php-zabbbix-api/php-zabbix-api",
    ...

[domibarton]

damn typo 😠
fixed!

[domibarton]

composer package available as confirm-it-solutions/php-zabbix-api