@piotr-cz opened this Issue on December 17th 2014 Contributor

Move PiwikTracker.php to own repository and add dedicated composer.json file.

Benefit: Library will be available to download and integrate into projects using package manager (composer/packagist), just like other API tracking Clients are.

ATM if you are using composer you have to include whole Piwik but include just PiwikTracker.php or not use package manager and handle updates manually.

There are other benefits like dedicated test suite and better exposure to community,

@mnapoli commented on December 17th 2014 Member
@piotr-cz commented on December 17th 2014 Contributor

How could I miss that?
Should I close the issue since it's labelled now?

@mattab commented on December 17th 2014 Owner

we can leave it opened, it was also duplicated in #327

@tsteur commented on December 19th 2014 Owner

It is included as a submodule to stay backwards compatible and to keep the libs/PiwikTracker path. We can have another branch in this repository for a refactoring and could include the refactoring branch at some point under vendor/... via composer. Just in case someone starts a refactoring

@JohnMaguire commented on December 7th 2015 Contributor

@tsteur What about committing a symlink from libs/PiwikTracker to the new location in vendor? Existing scripts would continue to work this way I believe.

@JohnMaguire commented on December 7th 2015 Contributor

However, that solution wouldn't support Windows (not sure if that's a target platform of Piwik or not.)

@tsteur commented on December 7th 2015 Owner

It is a target platform of Piwik

@JohnMaguire commented on December 7th 2015 Contributor

I don't want to beat a dead horse here, but I have one last proposed solution:

  1. libs/PiwikTracer.php -> <?php if (!class_exists('PiwikTracker.php')) require_once BASE_PATH . '/vendor/piwik/piwik-php-tracker/src/PiwikTracker.php';
  2. Add piwik/piwik-php-tracker to composer.json.

At that point, you could manage the tracker with composer with the rest of your dependencies, and existing code would continue to function correctly.

@JohnMaguire commented on December 7th 2015 Contributor

In fact, if you're planning to use the autoloading feature of composer with piwik/piwik-php-tracker, you would just needs libs/PiwikTracker.php to be an empty file to prevent errors.

@tsteur commented on December 7th 2015 Owner

If it works I would be totally okay with that solution :) Not sure if there would be any other downsides or disadvantages? We just need to make sure to not break BC in some way.

We'd probably need to adjust at least the Piwik build script eg here https://github.com/piwik/piwik-package/blob/master/scripts/build-package.sh#L19-L20

BTW: We would still have some submodules afterwards, eg log-analytics. But I think none of these submodules would be actually needed in order to use Piwik, only in specific cases. If we did this, one could setup a minimal Piwik by only using composer I reckon

@JohnMaguire commented on December 8th 2015 Contributor

Cool. :) I can't think of any major ones. The first approach (not having a blank file) is probably the safer solution -- if any other symbols are created inside the PiwikTracker.php file that the autoloader can't handle, they wouldn't be guaranteed to be in scope with the empty file / trust autoloader approach. But having the usual included file redirect to the one in vendor/ should function exactly as expected.

I'll implement this in the next couple days and play around with it a bit to make sure it works. On that note, I'll comment to hold off on merging the PR I submitted earlier today.

@tsteur commented on December 8th 2015 Owner

Sweet, thx for that. I will add a label work in progress to the PR

This Issue was closed on December 19th 2014
Powered by GitHub Issue Mirror