Apparently there is a utility that automagically zips this and that and then places the zips in download.moodle.org/plugins..... or I guess in download.moodle.org.
The zips are created with a parent directory that has no relation to the moodle infrastructure. This means that one can not unzip from the root and thereby complete an install, which means that directions for install are unnecessarily complex or the maintainer needs to bypass this nice moodle feature and build and maintain the zip somewhere other than the moodle (which seems to hbe contrary to the spirit of things, as it were....) Hey! Is this the reason that it sems that everyone has a moodle directory in their moodle!
So, the question I have is where there might be documentation on the scripts/utilities that create these zips automagically and whether there would be an issue with fiddling that so that zips are not archived with the added directory because a) it is unnecessary (anyone who wants the added infrastructure is free to make it), b) is it inconvenient (while you can easily unzip in any directory to wish) you can't unzip from an archival subdirectory, and c) it makwes installation a pain
If there are no specific reasons against such a move I will create a tracker item and look into fiddling the scripts...
The modules are zipped with their directory name because modules are self-contained and the name of the directory is important.
1) Download feedback.zip
2) Save it in mod directory
3) Unzip it and a "feedback" directory is created
4) Visit Moodle admin to complete the install.
Unzipping in the root will mean create problems because different zip programs work differently (sometimes they add a parent directory and sometimes not), and because people will start putting all kinds of different things with dependencies in each package (not self-contained and modular).
I'm not sure what you're advocating and what you mean about the "moodle" directory, it doesn't appear anywhere in the plugin zips.
1) Download feedback.zip
2) Save it in mod directory
3) Unzip it and a "feedback" directory is created
4) Visit Moodle admin to complete the install.
Unzipping in the root will mean create problems because different zip programs work differently (sometimes they add a parent directory and sometimes not), and because people will start putting all kinds of different things with dependencies in each package (not self-contained and modular).
I'm not sure what you're advocating and what you mean about the "moodle" directory, it doesn't appear anywhere in the plugin zips.
The problem is that as noodle starts offering "packages" in the sense that Anthony uses it here:
http://tracker.moodle.org/browse/MDLSITE-411
the functionality you describe is no longer universal.
unzip will create a parent directory if a parent directory is included in the archive and there is no way around that.
I have argued your position before (i.e. don't tell people to unzip unless you have details of where and how because it could in fact overwrite files) not because unzipping is bad (as opposed to manually renaming old files and copying new files) but because there were inadequate instructions in some cases (especially where something was not in the format you describe - i.e. a mod that needed to be unzipped to the mod's directory....)
but...
It would seem that each zip could have specific instructions as to how to install the zip.... so if one wanted to install for example some of the work Mauro is doing on editors, one could do that with a zip (though I have suggested that a facility like cpan or yast would be sweet!) without having to to move anything about....
and....
the dependency risk is always there, there are disclaimers (as has been pointed out to me before), and hopefully code maintainers will be responsible in their code and warnings.....
Much of this discussion is in a sense a mirror of the discussion that took place among Anthony, John and I regarding Dragmath integration (the lawyer in me argued your position actually....) and you could condisder the Dragmatn integration as the strawman for this argument, the Maunos work on editor integration will I think make this a very real issue very soon....
What I meant about moodle directories is that while some of us do not have a moodle directory, it appears that most who do a zip install do.... I have never done a moodle install from a zip, but based upon the discussion I am assuming that most end up with a parent moodle directory because that is how it is zipped. If one were to create a moodle directory in which to install moodle from a zip, my guess is that one would subsequently discover that one's code is in /moodle/moodle, no??
http://tracker.moodle.org/browse/MDLSITE-411
the functionality you describe is no longer universal.
unzip will create a parent directory if a parent directory is included in the archive and there is no way around that.
I have argued your position before (i.e. don't tell people to unzip unless you have details of where and how because it could in fact overwrite files) not because unzipping is bad (as opposed to manually renaming old files and copying new files) but because there were inadequate instructions in some cases (especially where something was not in the format you describe - i.e. a mod that needed to be unzipped to the mod's directory....)
but...
It would seem that each zip could have specific instructions as to how to install the zip.... so if one wanted to install for example some of the work Mauro is doing on editors, one could do that with a zip (though I have suggested that a facility like cpan or yast would be sweet!) without having to to move anything about....
and....
the dependency risk is always there, there are disclaimers (as has been pointed out to me before), and hopefully code maintainers will be responsible in their code and warnings.....
Much of this discussion is in a sense a mirror of the discussion that took place among Anthony, John and I regarding Dragmath integration (the lawyer in me argued your position actually....) and you could condisder the Dragmatn integration as the strawman for this argument, the Maunos work on editor integration will I think make this a very real issue very soon....
What I meant about moodle directories is that while some of us do not have a moodle directory, it appears that most who do a zip install do.... I have never done a moodle install from a zip, but based upon the discussion I am assuming that most end up with a parent moodle directory because that is how it is zipped. If one were to create a moodle directory in which to install moodle from a zip, my guess is that one would subsequently discover that one's code is in /moodle/moodle, no??
Marc - Thanks for the summary. As you see that key is to make sure that we provide accurate instructions about how to unzip. It seems to me to be a good strategy for folks to unzip to a temporary directory. Then we can tell folks to copy the files from /{mytemp}/{zipfilename}/* (be it moodle or dragmath, etc.) to /myproductionsite . Just to clarify what you mean about moodle directory you are referring to the /moodle directory created in the zip files like moodle-weekly-19.zip. When I wanted to unzip the file on a hosted site it was initially not clear to me that I would need to unzip to temp directory and then move the files. But unzipping to a temporary location gives folks a chance to ensure that they are installing what they think they are installing. In other words, they can browse and make sure that things care correct. Peace - Anthony
Yes and yes.
Initially I was a bit distressed at the idea of unzipping so that things get possibly overwritten and posted about that.... but there are ways to avoid that...
My real concern is to make that we have comprehensive directions so that whatever we say a user should do is what the user should do....
if we expect them to copy at a shell prompt then we should provide details as in:
cd dragmath
cp -R * /whatever
This evening I read a post by some poor soul who had been trying to set up a custom php.ini and ended up putting the code for a shell script to maintain php.cgi into cgi-bin ...... and was offering $20 via paypal for anyone who could help! I provided some simple comprehensive instructions and passed on the money when things were quickly fixed.... the instructions the person was trying to follow were fine for someone who knew what they were doing, but totally unacceptable for someone who didn't..... so if we expect all kinds a people to be playing with this we need to provide detailed comprehensive instructions or post anything a monkey can't do with a big skull and cross bones that says geeks only ;=}
So, if that is how we are going to go then I will update docs.
Initially I was a bit distressed at the idea of unzipping so that things get possibly overwritten and posted about that.... but there are ways to avoid that...
My real concern is to make that we have comprehensive directions so that whatever we say a user should do is what the user should do....
if we expect them to copy at a shell prompt then we should provide details as in:
cd dragmath
cp -R * /whatever
This evening I read a post by some poor soul who had been trying to set up a custom php.ini and ended up putting the code for a shell script to maintain php.cgi into cgi-bin ...... and was offering $20 via paypal for anyone who could help! I provided some simple comprehensive instructions and passed on the money when things were quickly fixed.... the instructions the person was trying to follow were fine for someone who knew what they were doing, but totally unacceptable for someone who didn't..... so if we expect all kinds a people to be playing with this we need to provide detailed comprehensive instructions or post anything a monkey can't do with a big skull and cross bones that says geeks only ;=}
So, if that is how we are going to go then I will update docs.