Posted by mlncn on June 20, 2007 at 9:39pm
To contribute several related Install Profiles, should they be put in a project with one folder and several profiles, a project with several folders and a profile in each, or separate projects altogether? Thanks!
Comments
Doesn't directly answer the
Doesn't directly answer the question, but CivicSpace built packages code that was not accepted into Drupal 6.
This allows you to build a package (a collection of modules and configuration) and then knit together a couple of packages into an install profile.
You can imagine a wiki package and blog package that can both be included in a profile.
Check with Kieran (kieran at civicspacelabs org) for more info.
"Not accepted"
What do you mean not accepted? 'Cause Drupal 6 isn't frozen for another week and a half. Do you have an issue tracker number for d.o., please?
CRUD, Data API, stuff to make configuration easier
Creating a library of CRUD API functions for Drupal
DataAPI:first steps
Cheers,
Kieran
P.S. I am shocked, shocked, shocked to find there is an issue you don't know about!
To seek, to strive, to find, and not to yield
New Drupal career! Drupal profile builders.
Try pre-configured and updatable profiles on CivicSpaceOnDemand
OK...
Heh :P I actually usually don't pay that much attention to granular issue stuff. Turns out that I did comment on the CRUD API one.
I was challenging David's comment that there was code that was "not accepted" -- since not accepted only happens once code freeze is done. And as it turns out, there is no package code in those issues.
CRUD API looks to be stalled, but there is somewhat recent activity on Data API. Got some suggestions on moving either/both forward? I would suggest the CRUD API one is simpler -- make consistency in core and use system.install and default.profile as examples of their use.
Packages is for contribution, CRUD is for core
Like many good ideas, there one approach for contributions and one approach for core to solve the same problem.
I think the DATA API is elegant core solution that could lead to Drupal having great data web services, similar to Google's DATA API, and consistent interface.
Nedjo's work on DATA API is the core approach to what CivicSpace did to pre-configure hosted profiles. I suspect once the consistency of DATA API is in place, then CRUD could follow.
Cheers,
Kieran
To seek, to strive, to find, and not to yield
New Drupal career! Drupal profile builders.
Try pre-configured and updatable profiles on CivicSpaceOnDemand
Short answer
Go for it. only .profile files are allowed in profile directories in any case (and .inc, etc.). This is similar to modules with sub module folders. You may have to re-organize this at a future date when Drupal.org does automation in order to package these profiles, but I don't see a problem with it.
I'll put multiple example_installer.profile files in a directory
Thanks for all the feedback!
Note that I did try putting a profile directory in a sub-directory (actually profile/contrib/agaric_starter/agaric_starter.profile) and while Drupal read the file to offer the profile, it broke on trying to go to the next step. So nested folders seems out for installation profiles. Maybe this is a bug?
So I'll put multiple example_installer_variation.profile files in a single directory
@Amazon: I haven't gotten close to catching up with Drupal 6, but I do think we really need CRUD functions for all of Drupal. I can't believe there's so much confusion about programmatically creating content types, for example. Everything a function!
~ benjamin, Agaric Design Collective
benjamin, agaric