|
|
# The problem:
|
|
|
|
|
|
## Primary:
|
|
|
|
|
|
**CiviCRM point-version dependency support:**
|
|
|
An extension may be known to work well under specific point-releases of the CiviCRM 4.7.x branch but not under others. Currently, extension developers have no way to indicate that incompatibility, and CiviCRM will happily install the extension under CiviCRM 4.7.1 even though the developer knows it won’t work on versions less than 4.7.23.
|
|
|
|
|
|
## Related:
|
|
|
|
|
|
**Extension dependency support:**
|
|
|
An extension may also require certain other extensions in order to work properly. Currently, CiviCRM lacks support for such dependencies, and developers are resorting to various ad-hoc workarounds to try and enforce them.
|
|
|
|
|
|
## Common thread:
|
|
|
|
|
|
These two problems appear to be subsets of the same thing: dependency management.
|
|
|
|
|
|
# Concerns:
|
|
|
|
|
|
* Version naming convention must be consistent for all extensions.
|
|
|
|
|
|
* Any system we implement must not block existence of existing extensions.
|
|
|
|
|
|
# Prior art:
|
|
|
|
|
|
* **WordPress plugin: "WordPress plugin dependency management":**
|
|
|
[https://github.com/xwp/wp-plugin-dependencies](https://github.com/xwp/wp-plugin-dependencies)
|
|
|
|
|
|
* Does:
|
|
|
* Check for existence of packages.
|
|
|
* Recurse as deeply as needed.
|
|
|
* Does not:
|
|
|
* Check for specific package versions.
|
|
|
|
|
|
* **Drupal 7 core:**
|
|
|
[https://www.drupal.org/docs/7/creating-custom-modules/writing-module-info-files-drupal-7x#dependencies](https://www.drupal.org/docs/7/creating-custom-modules/writing-module-info-files-drupal-7x#dependencies)
|
|
|
|
|
|
* Does:
|
|
|
* Check for existence of packages.
|
|
|
* Check for specific package versions.
|
|
|
* Recurse as deeply as needed.
|
|
|
* Does not:
|
|
|
* Support version ranges.
|
|
|
|
|
|
* **Composer: **
|
|
|
[https://getcomposer.org/doc/articles/versions.md#writing-version-constraints](https://getcomposer.org/doc/articles/versions.md#writing-version-constraints)
|
|
|
|
|
|
* Does not:
|
|
|
* Just automatically work with our extension directory infrastructure.
|
|
|
* Does:
|
|
|
* Everything else.
|
|
|
|
|
|
* **Some existing library that does everything, which we could just bundle in CiviCRM:**
|
|
|
|
|
|
* Does not:
|
|
|
* Appear to exist.
|
|
|
|
|
|
# Possible options:
|
|
|
|
|
|
* **Composer:**
|
|
|
|
|
|
* Pros:
|
|
|
|
|
|
* Already exists and is well used in PHP land.
|
|
|
|
|
|
* Addresses all the above-stated needs related to dependency management.
|
|
|
|
|
|
* Cons:
|
|
|
|
|
|
* Makes installing Composer a prerequisite to installing CiviCRM.
|
|
|
|
|
|
* Significantly raises the barrier to installation for low-budget users.
|
|
|
|
|
|
* Installing Composer on shared hosting can be difficult or impossible ([https://stackoverflow.com/questions/20894518/how-do-i-install-composer-on-a-shared-hosting](https://stackoverflow.com/questions/20894518/how-do-i-install-composer-on-a-shared-hosting))
|
|
|
|
|
|
* **Home-grown solution, a la Composer or Drupal 7**
|
|
|
|
|
|
* Pros:
|
|
|
|
|
|
* Could be bundled with CiviCRM without requiring Composer (see cons for Composer)
|
|
|
|
|
|
* Could borrow heavily from prior art.
|
|
|
|
|
|
* Cons:
|
|
|
|
|
|
* Oh God, we have to maintain it.
|
|
|
|
|
|
* A true satisfiability solver may be impossible ([https://en.wikipedia.org/wiki/Boolean_satisfiability_problem](https://en.wikipedia.org/wiki/Boolean_satisfiability_problem)), and even a good one is probably hard. We’ll need to manage scope and expectations well.
|
|
|
|
|
|
# Recommendations:
|
|
|
|
|
|
1. Ask someone smart like Tim Otten if he’s aware of any of these:
|
|
|
|
|
|
1. A way to bundle Composer into CiviCRM (i.e., get the *pros* without the *cons*)
|
|
|
|
|
|
2. An existing library that comes close to doing what we need.
|
|
|
|
|
|
2. If #1 turns up little, we should scope out a home-grown implementation, borrowing as much as possible from prior art. |