Installation profiles: here is what missing
Gerhard asked this in the current kitchen sink thread and the answer is IMO obvious: the package script is missing so that instead of a bare profile you can download a tarball. Who wants to work on this?
A package script would be great. May I flag something though: I'm finding a number of cases where I want/need to specify a version of a module. You can see a example definition file I'm using: http://cvs.drupal.org/viewvc.py/drupal/contributions/profiles/emspace/emspac... I'm interested in a group consensus on an ini file, be it by release name or CVS branches/tags. FWIW: the way I'm processing the file is: awk '$1=="m"{ print "echo \">> "$2" ("$3") >> "$4"\"" print "cvs -Q co -r "$3" -d "$2" contributions/modules/"$2 }' ../../../profiles/emspace/emspace_codebase.txt | csh .s
On 11 Nov 2007, at 9:23 AM, Karoly Negyesi wrote:
Gerhard asked this in the current kitchen sink thread and the answer is IMO obvious: the package script is missing so that instead of a bare profile you can download a tarball. Who wants to work on this?
I've been putting a considerable amount of thought into this recently (as I'm developing a considerably complex install profile at present), and I've considered that one of the largest obstacles with actually writing an install profile, is that for almost any thing we need to accomplish, we inevitably need some form of memory resident code. The only way to bypass this at the moment, is to ship a _support module along with it. This is not ideal. Essentially, install profiles are like trying to write a module using only the .install file. You can't really accomplish much with those limitations. What I suggest, is that we bypass this limitation, move what we currently call a .profile to a .install, and turn the inevitable _support module into the .profile. This should still imo be stored in profiles/ A simple modification to the loading code will allow us to ALWAYS include the profile in the module_list and loading (I think last in the chain is the best place to put it). We now have the ability to use the already existing .info management code for modules and themes, and then that allows us to much more easily write the package generation scripts. I'm not really convinced profile_final is necessary, as an _install hook could accomplish exactly the same thing, with the added benefit that we get NUMBERED SCHEMAS, which is a major drawback in our current system. While we could use CRUD to create a lot of the object we need to run the sites, it's not quite as manageable in the long term (especially without the current numbered schemas. it's frighteningly difficult actually) What I think works better in this case, is the $module_default_ $things functions (example : hook_views_default_views), that provide the default data object. According to eaton, cck v2 will have this feature as well (cck + install profiles don't really mix well atm, cck_import is quite hacky). I would also resurrect this patch of mine http://drupal.org/node/ 25745, which I actually need to do regardless. But what that would do, is allow the developer to specify $default variables in the same was as the $conf overrides (possibly in the _init hook which the profile now gets) Quite possible we would end up reducing code in this process, by getting rid of most of the special handling of install profiles, and a major added benefit we have, is documentation / education. If you can write a module, you can write an install profile. I'm not just suggesting this, I'm actually going to be working on patches to this effect in drupal 7, because I really believe we need to make these profiles useful.
Adrian You've identified a major issue for me. If my goal is to make happy with the usability, I can't seem to escape having a supporting module. I really appreciate the razor you've applied to this problem! I'm with you on this. An added benefit of the profile being active after install (based on my D5 experience here) is the ability to have a wizard. .s On Nov 11, 2007 11:00 PM, adrian rossouw <adrian@bryght.com> wrote:
On 11 Nov 2007, at 9:23 AM, Karoly Negyesi wrote:
Gerhard asked this in the current kitchen sink thread and the answer
is IMO obvious: the package script is missing so that instead of a
bare profile you can download a tarball. Who wants to work on this? I've been putting a considerable amount of thought into this recently (as I'm developing a considerably complex install profile at present), and I've considered that one of the largest obstacles with actually writing an install profile, is that for almost any thing we need to accomplish, we inevitably need some form of memory resident code.
The only way to bypass this at the moment, is to ship a _support module along with it. This is not ideal. Essentially, install profiles are like trying to write a module using only the .install file. You can't really accomplish much with those limitations.
What I suggest, is that we bypass this limitation, move what we currently call a .profile to a .install, and turn the inevitable _support module into the .profile. This should still imo be stored in profiles/
A simple modification to the loading code will allow us to ALWAYS include the profile in the module_list and loading (I think last in the chain is the best place to put it). We now have the ability to use the already existing .info management code for modules and themes, and then that allows us to much more easily write the package generation scripts.
I'm not really convinced profile_final is necessary, as an _install hook could accomplish exactly the same thing, with the added benefit that we get NUMBERED SCHEMAS, which is a major drawback in our current system.
While we could use CRUD to create a lot of the object we need to run the sites, it's not quite as manageable in the long term (especially without the current numbered schemas. it's frighteningly difficult actually)
What I think works better in this case, is the $module_default_$things functions (example : hook_views_default_views), that provide the default data object. According to eaton, cck v2 will have this feature as well (cck + install profiles don't really mix well atm, cck_import is quite hacky).
I would also resurrect this patch of mine http://drupal.org/node/25745, which I actually need to do regardless. But what that would do, is allow the developer to specify $default variables in the same was as the $conf overrides (possibly in the _init hook which the profile now gets)
Quite possible we would end up reducing code in this process, by getting rid of most of the special handling of install profiles, and a major added benefit we have, is documentation / education. If you can write a module, you can write an install profile.
I'm not just suggesting this, I'm actually going to be working on patches to this effect in drupal 7, because I really believe we need to make these profiles useful.
On 11 Nov 2007, at 2:20 PM, Simon Hobbs wrote:
An added benefit of the profile being active after install (based on my D5 experience here) is the ability to have a wizard.
or a profile specific settings page, which configures all the different components. I think there's room for all modules to have a post_install configuration wizard/screen. Install profiles could leverage the same hook to do the initial installation.
On Nov 11, 2007 1:20 PM, Simon Hobbs <emspace.com.au@gmail.com> wrote:
Adrian
You've identified a major issue for me. If my goal is to make happy with the usability, I can't seem to escape having a supporting module. I really appreciate the razor you've applied to this problem! I'm with you on this.
An added benefit of the profile being active after install (based on my D5 experience here) is the ability to have a wizard.
D5 install profiles can have one screen to display after the database configuration, Drupal 6 profiles can have their own "state machine" built into the installer after the "Configure site" screen and the "Finished" screen (also the Configure screen is form_alter-able). So any kind of install wizard is possible, without having a module. We are trying to fix bugs to make this kind of feature play nice with localization even here: http://drupal.org/node/190283 Gabor
All of the improvements to the install profiles are steps in the right direction, and I hesitate to bring this up because I have no desire to see this same thread rehashed, as it has been multiple times. Install profiles are made more complicated by the inability to distribute some 3rd party code along with modules. In my specific case, I'm thinking specifically of tinyMCE and the getid3 libraries. The need to get these libraries as separate steps eliminates/balances out some of the utility of the actual profile. Given that most of the profiles that exist to date target users with less technical proficiency, this can be a barrier to entry that makes the profile a less useful option. NOTE: I am *not* saying we need to revisit this issue. Please, let's *not* revisit this issue. Nobody needs/wants to have Yet Another Conversation about the place of 3rd party code on d.o So, in responding to chx's initial post, I would have to say the biggest issues I see are, in this order: 1. The inability to target specific versions of a module. 2. The inability to create an install package on d.o (which would take care of 1 if done well, but is also a LOT of work, and again, not something I'm saying needs to be done by anyone soon). 3. The inability to include 3rd party libraries as part of the package (and to emphasize: let's not have this discussion again) I would put the the ability to move packages (ie, all the cool stuff you can do with the CivicSpace APIs -- http://customprofiles.civicspaceondemand.org/api/file ) as 4th, simply because these other details are more basic usability issues. As a long term improvement, however, the packages work would save more people more time than any of these first three. With all that said, I also think that this conversation should be put on hold until after D6 is out. Any install profile improvements will start by leveraging the improvements mentioned by Gábor, and for D6 they should live in contrib. Cheers, Bill Gábor Hojtsy wrote:
On Nov 11, 2007 1:20 PM, Simon Hobbs <emspace.com.au@gmail.com> wrote:
Adrian
You've identified a major issue for me. If my goal is to make happy with the usability, I can't seem to escape having a supporting module. I really appreciate the razor you've applied to this problem! I'm with you on this.
An added benefit of the profile being active after install (based on my D5 experience here) is the ability to have a wizard.
D5 install profiles can have one screen to display after the database configuration, Drupal 6 profiles can have their own "state machine" built into the installer after the "Configure site" screen and the "Finished" screen (also the Configure screen is form_alter-able). So any kind of install wizard is possible, without having a module. We are trying to fix bugs to make this kind of feature play nice with localization even here: http://drupal.org/node/190283
Gabor
-- Bill Fitzgerald http://www.funnymonkey.com Tools for Teachers 503.897.7160
On 11 Nov 2007, at 4:50 PM, Bill Fitzgerald wrote:
With all that said, I also think that this conversation should be put on hold until after D6 is out. Any install profile improvements will start by leveraging the improvements mentioned by Gábor, and for D6 they should live in contrib.
umm. no. it's a core enhancement. this will only work cleanly if you modify the core bootstrap and module.inc functions such as module_list etc. The modifications aren't that huge either. Maybe 20 lines of code or so (guesstimate) to accomplish this. It's implausible to change how profiles work for the drupal 6 timeline. We can't require an additional module to alter the module workflow enough to make this all run (we'd end up sitting with the same situation as the _support module now).
On Nov 10, 2007, at 11:23 PM, Karoly Negyesi wrote:
the package script is missing so that instead of a bare profile you can download a tarball. Who wants to work on this?
I do. It's already in the works, and there's already some funding lined up. It was currently lower on my priority queue given the D6 port of project*[1], but I'm happy to reshuffle if the community thinks getting packaged install profile tarballs is a higher short term priority than getting d.o ready to upgrade to D6. Better yet, if more help materialized for the D6 port, we could have our cake and eat it too. -Derek (dww) [1] http://groups.drupal.org/node/6180
participants (6)
-
adrian rossouw -
Bill Fitzgerald -
Derek Wright -
Gábor Hojtsy -
Karoly Negyesi -
Simon Hobbs