Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of Core & plugins with git subtrees and Composer packages #6757

Closed
mnapoli opened this issue Dec 1, 2014 · 5 comments
Closed

Handling of Core & plugins with git subtrees and Composer packages #6757

mnapoli opened this issue Dec 1, 2014 · 5 comments
Labels
not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. RFC Indicates the issue is a request for comments where the author is looking for feedback.
Milestone

Comments

@mnapoli
Copy link
Contributor

mnapoli commented Dec 1, 2014

Goal: find a solution for:

We could use git subtrees and sub-repositories, for example:

  • / -> git repository & GitHub project (piwik/piwik) & composer package (piwik/piwik)
    • core/ -> git subtree & GitHub project (piwik/core) & composer package (piwik/core)
    • plugins/
      • CustomAlerts/ -> git subtree & GitHub project (piwik/plugin-CustomAlerts) & composer package (piwik/plugin-CustomAlerts)
      • ...

Regarding Composer, we would then use the replace feature, e.g.:

  • piwik/piwik replaces piwik/core, piwik/plugin-CustomAlerts, …
  • plugins require piwik/core (and not piwik/piwik), and maybe any other plugin: that way we can also run the tests for plugins independently from Piwik by just using Composer (which will install piwik/core and not the whole piwik/piwik)

Maybe all plugins could become subtrees? (to have their composer.json). That would mean a lot of repositories though.

This is what Symfony does so that symfony/symfony contains the whole framework, and then symfony/console is just the console component. Have a look at the composer.json. And as you can see, symfony/Console is just a read-only git subtree.

This is also what Laravel does, for example: illuminate/events.

Fabien Potencier mentioned in this article that he is using a script to maintain all subtree in sync with the main one, I'm guessing Laravel do the same. Maybe we could too.

Pros:

  • Piwik Core & plugins integrated in the main repo would have the same versioning as Piwik (which makes everything easier: same versions, same branches, same tags, etc...)
  • Each plugin could have a composer.json and be a Composer package
  • Piwik Core could be a Composer package by itself (allowing to be required by plugins, which would let us run plugin tests independently of the whole Piwik application, I like that)

What about the UI tests? I don't think this problem would be solved.


TL/DR: Do like Symfony with their components & bundles:

  • some are in their own separate repositories
  • some are in the main repository but with a git subtree, which lets them also be their own repository and composer package
@mnapoli mnapoli added the RFC Indicates the issue is a request for comments where the author is looking for feedback. label Dec 1, 2014
@mattab mattab added this to the Piwik 2.11.0 milestone Dec 1, 2014
@mattab
Copy link
Member

mattab commented Dec 2, 2014

@mnapoli thanks for starting the discussion and proposing this new idea! It certainly is interesting.
after 2.10.0 I think we should discuss further this idea with @mgazdzik and other interested parties.

@mnapoli
Copy link
Contributor Author

mnapoli commented Dec 19, 2014

The script Laravel and other projects use: https://github.com/dflydev/git-subsplit

@tsteur
Copy link
Member

tsteur commented Dec 22, 2014

I wouldn't create a tree for core as core is not really functional standalone as it requires a couple of specific plugins to work at all. There are calls from core to plugin classes. Eg to SitesManagerModel/API but also many many others which is a no go but it is there. So simply requiring core in a plugin will probably not work.

As said a couple of weeks or months ago I'd rather first try to extract eg the Tracker, the Archiver, into separate repositories and write them in a way that they can be reused and replaced. Also to simplify the code, to make it better understandable and testable. The core would require those packages and configure them etc. so that a developer can still configure Dimensions, Reports, etc in one plugin. This would be a lot of work (probably many months). Once this is done we could think about how to have a standalone core.

I would probably also not really create a tree for each core plugin that is shipped with Piwik by default. I do not really see an advantage here. Especially since they cannot be reused in any other application (which is the case for Symfony / Laravel packages). It would be different if our plugins would be truly independent AND we do not ship them by default. Then there would be a big advantage of being able to release / deploy new versions independently of core.

@mattab
Copy link
Member

mattab commented Jan 9, 2015

Drupal is about to git-tree their repo as well for some reason https://www.drupal.org/node/2352091#comment-9378633

@mnapoli
Copy link
Contributor Author

mnapoli commented Feb 2, 2015

I'm closing this issue because it mixes Composer and "getting rid of submodules".

The "getting rid of submodules" is discussed in #6605 (using git subtrees).

@mnapoli mnapoli closed this as completed Feb 2, 2015
@mattab mattab added the not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. label Feb 16, 2015
@tsteur tsteur mentioned this issue May 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. RFC Indicates the issue is a request for comments where the author is looking for feedback.
Projects
None yet
Development

No branches or pull requests

3 participants