Posted by dww on November 27, 2007 at 11:52pm
Yes: the maintainers should define where things go
0% (0 votes)
No: the locations should be consistent and hard-coded
78% (29 votes)
Compromise: allow both
22% (8 votes)
Total votes: 37
Comments
Explanation and analysis
This poll is part of the upcoming effort to package installation profiles with all of core and whatever contributed projects they depend on.
Should install profile maintainers have control over where contributed projects are included in the packaged tarball?
Yes: the maintainers should define where things go.
Pros
Cons
package[codefilter][version] = 5.x-1.0package[codefilter][target] = sites/all/modules/codefilter
package[cvslog][version] = 5.x-1.1
package[cvslog][target] = modules/project/cvslog
package[project][version] = 5.x-2.0
package[project][target] = modules/project/project
package[project_issue][version] = 5.x-2.1
package[project_issue][target] = modules/project/project_issue
No: the locations should be consistent and hard-coded.
Pros
package[codefilter] = 5.x-1.0package[cvslog] = 5.x-1.1
package[project] = 5.x-2.0
package[project_issue] = 5.x-2.1
sites/all/[modules|themes]/[project_name]Cons
Compromise: allow both
If the entry for a given project in the package array only contains a version string, we'll assume the target is
sites/all/[project_type]/[project_name]. However, if you define a nested array there with both aversionandtargetattribute, the packaging script will do what you ask.This sort of has all the pros and cons of both alternatives. ;)
Summary
I co-maintain the drupal.org testing install profile, so I'm not a complete stranger to install profiles. However, that's a relatively simple profile, and sites/all works just fine for our needs. So, I'd like to hear from some other install profile maintainers (or potential future maintainers) about if they think the additional flexibility is worth the added complexity.
profiles/foo/modules/*
The Drupal module system currently supports modules in the /profiles/foo/* directory as well as /modules and /sites/*/modules. Doesn't it seem like that's the logical location to hard-code things? If users copy a newer version of a module into sites/all/modules, it would override the profile-included copy, but wouldn't replace the overridden module on disk. That seems like the ideal solution...
Hard-coded, but not in sites/all/modules, then?
Ahh, I didn't know that. Thanks for sharing. So, for the purposes of this poll, you're voting "No: the locations should be consistent and hard-coded", you just think the hard-coded location should be profiles/[profile_name]/modules/* instead of sites/all/modules/*?
I'm not 100% sure I agree with this, but it's definitely worth considering. How about if this comes back overwhelmingly in favor of hard-coding, that we open another poll on sites/all vs. profiles/foo? ;) I guess we should have a "party line" about this, anyway, so that we have a recommended best practice for maintainers to follow if they define themselves, or if we go the compromise route what the default should be...
/me whips up a new poll. ;)
New poll on best practice for module locations
This sub-thread has now been moved to http://groups.drupal.org/node/7333 -- please comment/vote there, not here.
limited value for maintainer control
in order for "maintainers decide" to be useful, i think maintainers need the ability create new directories under sites. since thats a whole new can of worms, i think maintainer control is not very useful at this time. eton's suggestion of using profiles/foo/modules sounds good. in d7, we might even move the core install profile to match this convention (now i am getting bold).
Lock it down
As eaton mentioned, profiles/foo/[module|theme]/ exists for exactly this purpose. Let's use it. A module that cares where it lives needs to have a bug filed against it. I don't want to have to guess where my modules end up; if it's from an install profile, let it live in /profiles where it belongs.
Doing both, but...
A little late to the game, but here goes:
How about combining the two like
package_dir = sites/all/modules
package[codefilter] = 5.x-1.0
package[cvslog] = 5.x-1.1
package[project] = 5.x-2.0
package[project_issue] = 5.x-2.1
This would both allow profile maintainers to specify whether to put the given modules under profiles/, sites/all/, or somewhere else. Might need to call it "module|theme" instead of "package" though.
--
Frederik 'Freso' S. Olesen
--
Frederik 'Freso' S. Olesen
No limitation
Maintainers shouldn't be limited. For e.g. I'd like to integrate some other interesting modules a users should simply have - like CCK and Views, but i don't need them for my profile installation... so i'd like to have something like:
package[wiki][version] = 5.x-1.1package[wiki][target] = profiles/myprofile/modules/wiki
package[cck][version] = 5.x-1.7
package[cck][target] = sites/all/modules/cck
package[views][version] = 5.x-1.4
package[views][target] = sites/all/modules/views
package[mytheme][version] = 5.x-1.1
package[mytheme][target] = sites/all/themes/mytheme
package[mytheme2][version] = 5.x-1.dev
package[mytheme2][target] = sites/www.example.com/themes/mytheme2
package[de][version] = 5.x-1.dev
package[da][version] = 5.x-2.dev
package[ru][version] = 5.x-1.dev
package[fr][version] = 5.x-1.3
package[it][version] = 5.x-1.4
What becomes the path of translationals and what is about no fixed versioning???