Composer dependencies in plugins #32
Comments
|
Grav itself uses composer for it's supporting libraries that are stored in vendor. Currently we are stripping out extra folders (tests, examples, non-essential files) and actually pushing these into the Grav repo itself. We did this because originally we had planned on using *git subtrees so that the Grav repo could be 100% self contained. I.e. you could clone it and it would have everything including libraries, theme, essential plugins etc. Unfortunately subtrees in their current state proved troublesome when working with gitflow, and we quickly abandoned that plan. To get around this issue, we decided to just have a simple CLI command The question you actually asked is a bit tricker. A plugin is an optional install, also it needs to be self-contained. That is, you should be able to drop it into a Grav site, and with just minimal configuration perhaps, it should work. A unified composer really doesn't play well with this type of functionality. To get composer to add a library needed for a plugin, you would need to add that library to the What we have done in a couple of our plugins, is actually have the plugin have it's own Alternatively you could leave all the composer vendor folders out of the repo, just commit the Hope that helps... |
|
rhukster, Thanks for the perspective. It is interesting to watch a new product being developed and to have some view of the inner workings behind the design decisions. Thanks for making this project so open. Bob |
This commit enables the following approach
[chartjs]
type: bar
data:
labels: [Jan, Feb, Mar]
datasets:
- label: Bars Other Title
data: [1,2,4]
[/chartjs]
Significant limitation of this approach is that it (currently) requires disabling all Markdown
processing on the page to work. Would need some raw page processing to fix this, see
the TODO in the source code. It does at least try to detect and warn you off if you try
this approach without disabling md processing.
Huge benefit is that the strings used map 1-1 to the Chart.js library, so any Chart.js
parameters/datasets/options can be utilized. Also, folks can directly reference the
Chart.js documentation, no need to read the readme for this plugin to understand how
the options here map to chart.js options
In order to convert YAML to JSON (faithfully) you need a proper YAML parser. Rather than
asking folks to install a PECL extension, I went with the battle-tested Symphony YAML
parser. The license is MIT, so it should not conflict with this plugin’s license. I chose to
follow the format used in multiple other plugins (and kind of documented at
getgrav/grav#32 ) of embedding the composer “vendor” folder
directly into the git repo. Not what you typically do, but apparently that is the grav way.
I thought I would find a native YAML parser inside Grav (and it’s probably there somewhere)
but I gave up after a bit of looking and pulled in one I trusted.
My thoughts on using YAML (instead of JSON) inside the shortcode - A shortcode
is intended to allow for both quick writing and quick reading. IMO using raw JSON as the
contents would have worsened both the quick-writing and quick-reading nature of this
shortcode extension. As YAML is a pure superset of JSON, any JSON data can be
faithfully reproduced using YAML. If a user has any desire at all to go to raw JSON,
they can always paste that JSON directly into the markdown and bypass the shortcode
mechanism entirely. IMO the only negative of the YAML is that it makes it harder to
copy/paste chart examples into grav using this plugin, but I hope to address that by
adding some other functionality later.
If I right understand,
grav installonly can clone plugin from git repos. But now many projects usecomposerfor managing dependencies and autoloading.I think, must be provided some functionality, which run setup commands for plugins, e.g.
composer install.Thanks.
The text was updated successfully, but these errors were encountered: