|
Please consider the posts here http://moodle.org/mod/forum/discuss.php?d=95666&parent=423792
 http://moodle.org/mod/forum/discuss.php?d=95780&parent=423571
Are we talking about two different kinds of packages? I don't think so as it looks to me like this is what took place with dragmath.... and there are I think substantial issues with non-static sets of files. I think we need to some additional discussion in the forum regarding nomenclature.... What exactly is the dragmath issue?
I'm OK with this kind of idea as long as we're ONLY talking about modules ... as soon as we includes patched versions of files that are in core libraries etc then it becomes dangerous.
Martin - I agree, after speaking about patches I really see them more as temporary solutions. Packages would still be useful for more complex plugins that have a module and block. Peace - Anthony
FYI - GSOC contains an example of a package. Akshit Sharma created a customizable theme which has a block for dealing with user information so the custom_theme package would contain:
contrib/plugins/blocks/customtheme Peace - Anthony FYI - I am using the tracker to keep a list of the various pieces of contributed code that would make good packages. At this point, I see a package as being defined as the grouping together of two or more plugins that function in a unified way. The flexpage course format contains mod, theme, course format, block, etc. In CVS each would go into its respective directory and the package will pull together those zip files. Peace - Anthony
I'm thinking of creating sub-tasks of packages that need to be attended to once this is resolved. I'll add the attendance block and attforblock module to this list. Peace - Anthony
Oki,
so... it should support the aggregation of (exclusively) anything under http://cvs.moodle.org/contrib/plugins/ The point I don't see (after reading this bug again) is the one defining those package.txt files within contrib/packages/feedback. It can be done, of course but won't be easier to have only one packages.txt file (under contrib/tools/packager or so) controlling all the packages to be built? That way everything will be centralised in one file, easier to track and control. Just one idea. Ciao Eloy - Initially i was thinking that this would be something the maintainer would provide with the code; however, in order to keep control over it I think it would be better as you suggest to have a single package list. So my +1 for a single file. Peace - Anthony
And the idea is to unzip it in moodle root folder to get everything installed in place, correct?
Also... could packages.txt format be something like: packagename:oneplugin;anotherplugin;.....;lastplugin that with example data will look like this: #packagename:oneplugin;anotherplugin;.....;lastplugin
(note I've added the _package suffix to all packages in example, perhaps it's a good idea to name all them that way to avoid possible confusions with individual plugins with the same name. This can be automated of course, leaving "_package" out from the packages.txt file but adding it automatically on creation). Eloy - I think all of what you say above looks perfectly fine. In terms of the download and generation of the zip files I would want to have the ability to download from:
http://download.moodle.org/download.php/contrib/packages/feedback.zip As for the package suffix, that would be fine if you think it would help. Would you envision that changing things so that the download URL would include it or would that be automatically added as needed? I'm OK with having the suffix if it actually provides benefit; otherwise, since those who will have access to the packages file and those working with it will just be developers (and mostly me, and in rare situations) we might be able to avoid it. But I don't have strong feelings either way so if it is beneficial or makes things easier for you by all means feel free to use it. Peace - Anthony yup, yup. Packages will be available in that sort of URLs, agree 100%.
About the names, I thought about to append "_package" to all them because, that way we avoid conflicts between feedback.zip (the module) and feedback.zip (the package). I can imagine people downloading them and then trying to uncompress in the wrong place (the package within "mod", for example). http://download.moodle.org/download.php/contrib/packages/feedback_package.zip I know it's a bit repetitive to have "package" both in the path and in the name of the file but I think it'll help people downloading and installing a lot of things. It 100% the same for me (when creating the packager). But I feel having unique names will help moodlers in general. Ciao Sounds good to me or as Picard (TNG) would say "make it so". Thanks for working on this. While there are not that many examples, it will be very helpful when it is needed. Peace - Anthony
My plus one for this too. My attendance mod/block people would like a single download, but we do need to make sure they can tell them apart so as to avoid mis-installation issues.
Done.
All the source code for packages generation is here: http://cvs.moodle.org/contrib/tools/package_builder/ build.sh - the script in charge of generating everything Code is only in HEAD (and only will be there). I've added one example package: feedback_package:mod/feedback;blocks/feedback and you can see how it's available for download here:
Right now packages are built daily. Just add new packages definitions to packages.txt all they will be built in some hours. Both Anthony and me are receiving mails about the package generation daily (useful to find errors and so on). Please, use and watch the packages.txt file carefully. I'll leave this open some days...ciao Eloy rocks! What a great present and just in time for the celebration of Los Tres Magos
 Peace - Anthony Resolving as fixed (implemented). Daily generation working ok. Feel free to reopen if necessary.
Perhaps we'll need a page in download showing all the available packages (or whatever we name them)? Once we have a bunch of them... I think i'll be useful. (Use new issue for that, plz). Ciao Anthony, please add next package:
attendance_package:mod/attforblock;blocks/attendance Hi,
I've added your package as requested (if I'm not wrong Anthony is going to be out some days). It should be available tomorrow (if nothing fails) at:
Ciao (and thanks) Thanks Eloy for following up on the attendance package! One less thing to do as I try to catch up
 Peace - Anthony Eloy - Before re-opening, I wanted to check and see how you had handled the various branches. For example, with feedback there should be a 1.7 and 1.8 branch in CVS; however, it did not seem to have created : http://download.moodle.org/download.php/packages17/feedback_package.zip
and : http://download.moodle.org/download.php/packages18/feePeacdback_package.zip. Ideally, I think it should create one for each branch available. Peace - Anthony Ah, yes, Anthony,
right now... we are only building 1.9 and HEAD packages (I think you should be receiving 2 emails daily about that generation, yup?). But that's simply, because I limited that, because of 1.7 and 1.8 becoming older and older. Do you want me to start generating 1.7 & 1.8 packages? It's only a matter of enabling that in the server. Ciao Done.
You should have received two emails about 1.7 and 1.8 generation and packages should be available at their respective directories (packages17 and packages18). Will be regenerated daily, like the rest. Ciao Eloy - Giving it some more thought, I do not think that we need 1.7 since we generally discourage folks from using that version in favor of at least 1.8 I think there are enough 1.8 folks out there yet that it may be helpful to go ahead and enable it. I'm glad to hear that it would be pretty simple to do so. AFAIK, I have not been receiving any daily emails. Which email address is currently being used? I would suggest using contrib@moodle.org but you can also use anthony@moodle.org since they both go to the same place (arborrow@jesuits.net). Although I do recall seeing something when a commit change is made but nothing like a status or completion report. That would be good to have (but not essential). Peace - Anthony
Excellent - thanks, it does not hurt to have 1.7. Although I do not think I am receiving the emails. Peace - Anthony
Ah, my fault. I was sending emails to: aborrow@jesuits.net (missing "r"). Just switching to contrib@moodle.org ...
Ciao np, I just received the emails - mil gracias
Eloy - I wanted to get your take on a possible use of package. It involves something that would technically be a patch. For example, I'm looking at
) which was Eloy - I spoke with MD about
page_package:page_package:plugins/blocks/page,patches/block_page Notice that I added the plugins at the beginning. The easiest way I can see implementing this by changing the SOURCE_PATH to contrib rather than contrib/plugins. That way it would only require adding /plugins to the beginning of each of the VALID_PLUGINS and adding patches to the list. I can make all the changes with the exception of the cron job on the server that provides the initial SOURCE_PATH. How does this sound to you? Peace - Anthony Hi, hehe, I was sure your were going to comment about that in less than 2 hours (btw I missed your previous comment 1 week ago, sorry).
I'm going to play a bit with that... to confirm that only that change is necessary (because I think that will cause one "plugins" dir to be created in the root of the package... and I'm not sure if that is ok, because unzipping in moodle root dir won't work any more). Assuming that we need to leave all the plugins/whatever stuff into the root level of the zip file.... can you imagine a place to extract those patches? Perhaps one simple patches dir will be enough? With automatic instructions about how to apply it? Ciao Eloy - I was so happy to have packages that I didn't even consider patches. In terms of time, no worries as I've been pretty busy myself. I would say that we definitely do want the unzipping of plugins to continue to work so that they can be unzipped directly to the user's moodle root. If we need to wait and make some changes to the script, I would rather wait and do it right than rush so please take whatever time you need. I see no reason why we could not have a simple patches directory in the zip file and instructions for the users to check out http://docs.moodle.org/en/Development:How_to_apply_a_patch
. Ideally this should be able to hold multiple patch files. Thinking of the case where a package might be defined as containing multiple patches I wonder if each patch should create its own subdirectory under the patches folder. I'm thinking of the case where two patches might both have README.txt files. Does that make sense? Peace - Anthony Eloy - I am just now finding opportunity to take advantage of generating a good README.txt file for a package. Nice job anticipating the need for this. Simple but slick! Peace - Anthony
|
||||||||||||||||||||||||||||||||||||||||||||
New Feature
Resolved
Trivial
Download: Ability to package several directories in CVS into a package
 |
|
+1 to advance in this area.