I have a question that I would appreciate some feedback on regarding how best to handle CONTRIB plugins which make use of other libraries. When possible, my inclination is that the Moodle CVS should be reserved for Moodle related files. When an external library, for example jsmath is needed, that code should not be stored in CONTRIB but rather have the installation instructions provide instructions for downloading from the original source and where to unzip the contents of that library within Moodle. This has come up in reference to CONTRIB-1600 but previously there was a zip file added for a jsmath filter. Any suggestions, thoughts or ideas on how best to deal with such libraries so as to avoid duplication and other potential problems would be appreciated. Peace - Anthony
In reply to Anthony Borrow
Re: CONTRIB - projects with common libraries
Dear Anthony borrow,
when reading this, two things come up to my mind.
1. Installation/Integration can become tedious
2. Earlier version support may not be avail after new version release.
But yes i agree,for all practical reasons when people use external libraries its wiser to just provide links and instructions to install/integrate them with their application so that we can avoid replication and space wastage in here.
But any suggestions on handling the above 2 points ?
when reading this, two things come up to my mind.
1. Installation/Integration can become tedious
2. Earlier version support may not be avail after new version release.
But yes i agree,for all practical reasons when people use external libraries its wiser to just provide links and instructions to install/integrate them with their application so that we can avoid replication and space wastage in here.
But any suggestions on handling the above 2 points ?
I hit this problem with my Uploadpdf plugin.
I need 3 'external' components to get it working - ghostscript executable, TCPDF library, FPDI library.
The ghostscript executable makes sense to install separately (esp. as it needs to be the correct version for the server OS).
For the other two, whilst I like the idea of them being kept separate, for the sake of neatness and (very slight) space savings, I really don't fancy the install instructions needed by this (I still get quite a few emails about installing ghostscript - despite reasonably detailed instructions - having to download and install, to the correct folders, two extra libraries would be just too much).
Also, as the libraries don't (in my case) get updated very much (or at all?), there is only a single copy stored in CVS, rather than all the different versions of my files (which are updated fairly often).
Hope that helps the discussion a little...
I need 3 'external' components to get it working - ghostscript executable, TCPDF library, FPDI library.
The ghostscript executable makes sense to install separately (esp. as it needs to be the correct version for the server OS).
For the other two, whilst I like the idea of them being kept separate, for the sake of neatness and (very slight) space savings, I really don't fancy the install instructions needed by this (I still get quite a few emails about installing ghostscript - despite reasonably detailed instructions - having to download and install, to the correct folders, two extra libraries would be just too much).
Also, as the libraries don't (in my case) get updated very much (or at all?), there is only a single copy stored in CVS, rather than all the different versions of my files (which are updated fairly often).
Hope that helps the discussion a little...
Hi Anthony,
thanks for opening this discussion. I fully understand the arguments for keeping 3rd/external libraries outside our CVS. One the other hand - keeping your Moodle code working with all available library versions is hard, if not impossible. Note that even with Moodle core, a lot of external libraries are shipped. Sometimes we patch them to fit our needs. And the maintainer of the Moodle port must usually test every new update, watch their changelogs etc.
So, my +1 for
thanks for opening this discussion. I fully understand the arguments for keeping 3rd/external libraries outside our CVS. One the other hand - keeping your Moodle code working with all available library versions is hard, if not impossible. Note that even with Moodle core, a lot of external libraries are shipped. Sometimes we patch them to fit our needs. And the maintainer of the Moodle port must usually test every new update, watch their changelogs etc.
So, my +1 for
- appealing to our good contributors for trying to use Moodle core libraries whenever possible
- if external library is needed, it can be shipped with the plugin. However, the contributor should try to minimise the required disk space*). Also, copyright notice and license information must be kept. It is sort of policy in Moodle 2.0 to keep readme_moodle.txt file with additional information on the library integration.
As one of the authors of the plugin mentioned, and a newcomer to moodle, I can only explain my reasons for including all the libraries. We ship a full version of jsmath, and also a version of flowplayer, which is also present in moodle (though we ship a newer version).
In general, the reasons cited above apply, but I'm going to be as honest as possible. These were my reasons for including everything:
Let me go through the motivations more slowly:
The point is we have a plugin that is reasonably easy to install and to use and reasonably stable, and we did it the scarce time we had available. Now we can expect some people to come, use it and tell us their experiences. When they do, we will know better what to do, and may do severe refactoring. We'll also be more motivated to working on a plugin which, at the moment, has no users. I think it's too early to spend our time on reducing dependencies if this will scare some potential users, and if we can use our time with other issues about the plugin. Anthony Burrow has pointed some, and we have a few others in our checklist.
Regards
In general, the reasons cited above apply, but I'm going to be as honest as possible. These were my reasons for including everything:
- Installation is simplified a lot.
- Our time is limited.
- We don't have users yet.
Let me go through the motivations more slowly:
- Currently there are tons of high quality free software available, such as jsmath, flowplayer and s5-slides.
- Combination of these pieces of software allows for complex plugins to be developed with very little coding.
- So, most of the research goes into finding the right thing to do (and the right software pieces).
- That research can only be completed when you have users and you receive their feedback.
The point is we have a plugin that is reasonably easy to install and to use and reasonably stable, and we did it the scarce time we had available. Now we can expect some people to come, use it and tell us their experiences. When they do, we will know better what to do, and may do severe refactoring. We'll also be more motivated to working on a plugin which, at the moment, has no users. I think it's too early to spend our time on reducing dependencies if this will scare some potential users, and if we can use our time with other issues about the plugin. Anthony Burrow has pointed some, and we have a few others in our checklist.
Regards
Thanks David for your comments which confirm for me both that there are good reasons to allow for external libraries to be maintained on Moodle's CVS server but also that when we do so it should be with a degree of intentionality such that the purpose is to ensure compatibility, handle customizations that have been made, etc. When possible, I will ask the question if adding such libraries can be avoided but if there is good reason to include them then we can. In Pablo's case, for compatibility purposes it sounds like it may be good to have them. We will see how things continue to develop and if a particular library seems popular then we determine how it might best be handled. Ideally what I would like to avoid is that one plugin uses one version of a library and some other plugin uses another version of the same library. At this point it is not an issue but something I would like to keep in mind as I look at code. I appreciate the help in thinking this through. Peace - Anthony
I think it clearly comes down to stability of the library. Stability in two senses:
- it is maintained actively, security-wise (so it's reasonably low-risk re security bugs)
- it has a stable API -- function calls / OO methods aren't changing
If a library is stable, doesn't overlap with existing libraries we ship, and is used by various modules in CONTRIB, then it makes sense to push to have it in Moodle's core CVS, as part of the 'lib' directory.
Before all that is true, it makes sense to have a copy inside each CONTRIB project directory; this is specially true if the API is not stable (so you need a specific version), or not well maintained (so you'll need to carry patches to it yourself).
Otherwise, it might be a better idea to provide instructions to download/install.
Thanks - it is clear that there are multiple reasons for including the code and seems that it actually may be more of an exception when it would be considered part of the install to download and install a library from its original source. I appreciate the various perspectives and insights. Peace - Anthony