Effectiveness of install profiles?
Having worked recently on install profiles with the Filmforge project and the install_profile_wizard module, I am becoming less and less confident in their effectiveness. There are three key issues that need to be adressed IMO.
First, install profiles are currently prone to failure when you have different versions of modules. Install profiles should be able to list the version (update) number of each module currently installed, in order to be able to make the necessary updates during the install.
Second, install profiles are kind of "heavy". What I mean by that is that they merely correspond to a specific configuration of your database. In that case, wouldn't it be much more easy to have a tarball of your modules and a dump of the database? In many cases, I don't really need just a "blog" or a "wiki", I often need a set of specific configurations that I would like to install easily, like, I dunno, a configuration of tinymce for all of my contents (which implies settings in Tinymce but also in input formats and roles/permissions), or an image gallery with views, imagefield and thickbox. I think it might be a good idea to be able to create such modular "configuration profiles" that, combined together, would generate an install profile.
Third, I think there's a big problem with the way CRUD.inc (install_profile_api) is developed, even though I think it is important to have such an API. I'm pretty ok with having an API for the core modules (like, functions to create menus, blocs, etc), but why are there functions for tinymce in crud.inc? It should be the tinymce's module responsibility to provide such functions IMO.
These are just questions I want to raise, in order to generate a discussion. I don't have answers yet, I just feel it's important to raise these issues if we want to make advances at this step.
Yep
1) install profiles should be able to specific versions for modules, yes. I see this in part being solved when we have install profile generation support on Drupal.org, which will have a manifest file that lists the specific required modules, including specific branch/tag versions. Work and planning on this welcomed!
2) they are for freshly installed sites. As I've said before, CivicSpace's "packages" concept is superior, so I hope it is open sourced at some point so we can use that instead. Install profiles can be versioned and updated over time and so are the right direction ... do not play the fool's game of DB dumps :P They are not maintainable in the long term. Current method for updating install profiles over time is to ship a your_install_profile_support.module which can have an update schema in it.
3) I've mentioned that before. It's not a solved system. Every module needs to have it's own "data API", public functions to do settings and so on....but we don't even have this for core yet. For D5, and D6, we unfortunately will likely need to continue to roll our own. Splitting out support for different modules into, for instance, tinymce_install.inc etc., might be something we can do to make things a bit cleaner.
If you have control over a module, try setting settings within it using just functions (i.e. not DB queries). If you can't, please add them!
Install profiles and distributions continue to be a "call to arms" ... unless we work together and discuss how to go forward, they won't.
Thanks for kicking off discussion again....
Interesting post. I have
Interesting post. I have been looking at CivicSpaces "packages" module. What I like with this approach is that from what I understand, they can be applied upon installation but even afterwards. Anyway, from my own current experience, what we usually need is a way to quickly implement a set of atomic functionalities.
Sad, as you said, that the code from CivicSpaces "packages" is closed. It seems pretty heavy stuff but I will even consider re-coding it (the API is publicly available, which at least leverages a bit the analysis).
My reluctance...
I'll admit I haven't been following the projects progress since my initial let-down but:
The stumbling block for me was profiles complete ineffectiveness to work with contrib modules on a clean site.
Without a download/autoinstaller for dependancies, a profile was a hollow shell of instructions that didn't really help me much.
I figured out what I would need in a profile and set it up.
Tested it on a fresh Drupal installation and...
... all the required modules just weren't there. Failure. Predictably, I guess, but there was no easy way forward.
I expect that the work being done on distros and updates will at some stage converge with this needed functionality, but until then, it's not really serving any purpose to me, as all it will do is mix up permutations of settings available in drupal core.
I imagine that they are more practical in multisite setups, where you install once in sites/all/modules ... but that's not my development target.
So yes ... for what it's worth, I am currently better off snapshotting a total site+db and calling that my base 'profile'
See also My autoinstaller - 'Do CVS' insecure, but handy.
Now's the time to voice your opinions on packaging
Please see the 4 polls I just posted to this group about packaging install profiles along with core and the specific versions of the projects they depend on. See the summary in the forum on d.o: Input requested for installation profile packaging.
Cheers,
-Derek
I agree that whatever is
I agree that whatever is required for the profile that it should serve as a complete Drupal install. I think what Ubercart does is great: http://install.ubercart.org
I have used that installer numerous times and only once (in the beginning) did it throw some errors.
In some ways I am wondering if we need to reassess who will be using these installation profiles? IMO I was thinking early on it would be new Drupal users. I mentioned last night on #drupal that these profiles would help build the community if enough types (wiki site, gallery site, ecommerce site etc) were available. So another words, new users. For those who want to add something on later, once they have a live site going for some time, will need to do it the old way, for the time being.
Anyway, that is my 2cents. I would like to see a better solution for new users - in the end it will drive traffic/users to Drupal.... And maybe steal some traffic/users from other CMS sites like WP :)
===
Elvis McNeely
Blogging about Drupal and web development: http://www.elvisblogs.org/drupal
Offering Drupal, eCommerce and Web services: http://www.lafayetteweb.com
hrm a bit disturbing for an
hrm a bit disturbing for an ecommerce site to access their site via unencrypted/unfirewalled FTP and db, and compound this by accessing both via third-party unencrypted HTTP site.
When you download a snapshot
When you download a snapshot of Redhat and install it on your computer, how can you know for certain you can trust the installation? Because it is an OS piece of software and whoever makes the last update to the snapshot could do something "evil". For me I see no difference between that or an installer. Besides, it is a fresh install (of Ubercart) and if you go through the process the installer says it will overwrite files and tables.
===
Elvis McNeely
Blogging about Drupal and web development: http://www.elvisblogs.org/drupal
Offering Drupal, eCommerce and Web services: http://www.lafayetteweb.com
Big difference
Well, there is an important difference.
In Red Hat's case, you have the MD5 checksums, that guarantee no tampering has happened to the ISOs from third parties. Moreover, if the hack happens to a snapshot downloading before that is safe.
If you do not trust RedHat themselves, you can download all the source, and inspect it before compiling it and make sure it is all safe. Well, of course this is labor intensive, but you can hire someone to do the audit for you. Well, other people have already done that for you, it is called CentOS.
Now for XYZ installer, let us assume that a service like that is run by trustworthy and reputable people (as the case is with Ubercart today), and that their claim not to capture/store passwords is genuine.
There is no way to verify that claim at all. The code behind the installer is not available, and even if it is, you can never be sure that they have a custom version running different from the published code. Even Drupal.org has customizations to the core Drupal code base.
Moreover, if the XYZ installer site gets hacked, and someone installs an app that siphons off the user names and passwords, you will never know that it has happened.
So, they are not the same thing. Trusting a random site on the net with FTP and database passwords is not good practice at all.
Drupal performance tuning, development, customization and consulting: 2bits.com
Personal blog: Baheyeldin.com