Have you looked into profiler (http://drupal.org/project/profiler)

Seems like a simpler option to manage install profiles where the dependency/functionality is based largely on features. As the profile can be maintained an just an info list of modules to enable.

Comments

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

There's also http://drupal.org/project/install_profile_api and maybe one or two others that are supposed to help in this area.

I agree there can be benefits here, but worry about how far we build the dependency chain.

http://drupal.org/project/usage/profiler isn't encouraging.

univate’s picture

univate commented

install_profile_api - provides a bunch of functions to create content types, roles etc.. - this is what features does, so its functionality is mostly redundant when also using features.

http://drupal.org/project/usage/profiler isn't encouraging.

Thats probably because its not a module and the suggestion is to put it into a libraries directory and only load it during install, so my guess is its doesn't get reported to drupal via update module.

What I like is the *.profile file you can just put in:

!function_exists('profiler_v2') ? require_once('libraries/profiler/profiler.inc') : FALSE;
profiler_v2('buildkit');

Then create an *.info file:

name = Conference Organizing Distribution
core = 6.x
description = This software will help you organize a conference-style event.
theme = garland

; Core
dependencies[] = block
dependencies[] = filter
dependencies[] = node
dependencies[] = system
dependencies[] = user
dependencies[] = dblog
dependencies[] = comment
dependencies[] = help
dependencies[] = menu
dependencies[] = taxonomy
dependencies[] = path
dependencies[] = profile

; Contrib
dependencies[] = checkbox_validate
dependencies[] = admin
dependencies[] = pathauto
dependencies[] = globalredirect
dependencies[] = path_redirect
dependencies[] = comment_notify
dependencies[] = ctools
dependencies[] = context
dependencies[] = strongarm
dependencies[] = token
dependencies[] = content
dependencies[] = content_permissions
dependencies[] = fieldgroup
dependencies[] = number
dependencies[] = optionwidgets
dependencies[] = text
dependencies[] = filefield
dependencies[] = imagefield
dependencies[] = nodereference
dependencies[] = userreference
dependencies[] = link
dependencies[] = auto_nodetitle
dependencies[] = imageapi
dependencies[] = imageapi_gd
dependencies[] = imagecache
dependencies[] = imagecache_ui
dependencies[] = jquery_ui
dependencies[] = date_api
dependencies[] = date
dependencies[] = date_popup
dependencies[] = date_tools
dependencies[] = date_timezone
dependencies[] = views
dependencies[] = views_ui
dependencies[] = signup
dependencies[] = uc_cart
dependencies[] = ca
dependencies[] = uc_order
dependencies[] = uc_store
dependencies[] = uc_payment
dependencies[] = uc_product
dependencies[] = uc_signup
dependencies[] = flag
dependencies[] = features
dependencies[] = diff
dependencies[] = cod_session
dependencies[] = cod_events
dependencies[] = cod_attendees
dependencies[] = cod_front_page
dependencies[] = cod_news
dependencies[] = cod_sponsors

*.make just needs profiler:

libraries[profiler][download][type] = get
libraries[profiler][download][url] = http://ftp.drupal.org/files/projects/profiler-6.x-2.0-beta1.tar.gz
coltrane’s picture

coltrane
he/him
commented

Profiler seems pretty cool, for it's match of .info syntax and the sub-profile functionality. That seems great for something like a sub COD profile for DrupalCons! Have to think on this some more though.

sirkitree’s picture

sirkitree commented

+1

I've used profiler on a few projects now and would certainly help out int his area. It really is pretty sexty and also gets you into the right frame of mind when upgrading to D7 which uses the same syntax.

coltrane’s picture

coltrane
he/him
commented

I looked at Profiler a bit but can't say I understand many benefits to moving to its use. How does it "help out in this area"?

If we already have a bunch of .profile code written, what do we gain out of moving to it? @sirkitree, can you elaborate on what you like about it?

A reason I'm leaning towards it not being worth it is it adds one more dependency.

sirkitree’s picture

sirkitree commented
Assigned: Unassigned » sirkitree

The top thing I like about it is it's readability and simplicity. Much of the cod.profile's code can be simplified and thus, easier to maintain, though, it is fairly simple right now.

Another thing profiler might be good for is subprofiles. If we have the base profile setup, individual project can use this one as a base and create new ones that extend it. For instance, when coming up with a new DrupalCon site, we use this as a base, but if we want to add anything to it, we create a new subprofile that has any new modules or patches. This would mainly be nice for documentation purposes going forward, but it would give the next team a very easy way to see how the base cod profile was extended for a particular DrupalCon. Then, if the same modifications keep happening in subprofiles, they would be likely candidates for inclusion into the base profile.

I'll work on a patch that converts the .profile into profiler ready syntax in order to highlight the difference. Then we can decide if we think it's worth using or not.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Active » Postponed

@sirkitree - are you still interested in this? Overall my sense is that the benefits to COD are minimal so we would really just be getting the benefits to sub-profiles and I'm not sure 1) how big those benefits are 2) how likely people are to make sub-profiles (though I get the chicken-and-egg situation there).

japerry’s picture

japerry
Location KOMK
commented

I don't think we'll need this either, lets re-evaluate it after the sprint this weekend and see if there is a need for it.

japerry’s picture

japerry
Location KOMK
commented
Status: Postponed » Closed (won't fix)

Decided that we don't need this. Closing.