Posted by dww on November 27, 2007 at 11:52pm
Yes: maintainers can specify exactly where certain files are placed
11% (4 votes)
No: everything from the profile itself is included in profiles/[name]
89% (33 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 maintainers be able to place files in arbitrary locations in the installation profile's directory tree?
Note: this question is related to but separate from the question of Should install profile maintainers have control over where contributed projects are included in the packaged tarball?. That question is about defining where the external contribs are included inside the install profile's directory tree. This question is about if certain files in the install profile's CVS directory can be moved into other locations in the directory tree during packaging.
The most obvious use-case I can come up with is if an install profile maintainer wanted to place an extra README-[profile_name].txt file in the root of the directory tree. For example, the Conference organizing distribution might want to include a
"README-conference-organizing.txt" file in the root of the directory tree for additional user-facing documentation, instead of hoping that users will find the profiles/cod/README.txt file and use that.
Another potential use would be additional documentation inserted into the directory of certain key contrib modules used by the install profile.
Yes: maintainers can specify exactly where certain files are placed
Pros
Cons
No: everything from the profile itself is included in profiles/[name]
Pros
Cons
Summary
I don't think the issue about inconsistencies with tarball vs. CVS deployment is a big deal, I'm only including it for completeness. However, I also don't believe that the other complications and problems with this functionality are worth the potential flexibility. But, 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 and trouble.
Conflicting versions
In large installlations you might require several different versions of modules in the same tree.
This is not ideal, but is a possibility, and we habve the visibility in profiles/* for this specific reason.
--
The future is so Bryght, I have to wear shades.
Off-site
I'm afraid that such profiles might have to be hosted off-site. We could probably allow these profiles to still use drupal.org for issue tracking and be listed for download. My .02
Can you explain this?
I don't understand why you'd ever want this, regardless of the size of the installation. Can you please give a concrete example? Thanks.
documentation
What about just allowing documentation (txt files) to be allowed at higher levels in the structure?
Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.mattfarina.com
Doesn't really change much
Sure, we could add such a restriction, but it doesn't really change anything about the original question here. You still have to a) increase the complexity of the .info files, b) deal with potential conflicts/collisions, c) add more complexity to the packaging script. So, the restriction of only allowing placement of .txt files doesn't really simplify anything. Whether this is a good restriction or not should be discussed only if we decide we really want to allow any of this functionality in the first place. Thanks.
what about directories?
I admit, I wouldn't have thought of this, but now that the idea is out there, I could see putting files and directories (which in CVS require a file in them..correct?) in specific locations. For example a complex media centric profile could have subfolders pre-configured in the files directory to organize different types of media, by content type and module.
thoughts on directories
a) I'm a UNIX head. Everything is a file. ;) When I said "place files in arbitrary locations", I really meant "place files and directories...". ;)
b) I'm not sure what you're talking about regarding CVS requiring files inside directories. But, it doesn't matter for the purposes of this discussion -- I'm talking about what the directory tree looks like for the packaged tarball, not what happens if you check something out of CVS.
c) This specific use case (creating subdirs in the files directory) seems like a dubious example. Any module that's doing something specific in the files directory should be creating its own subdirs automatically, so that it works whether or not you installed it via the right install profile. That said, there probably are reasonable use-cases to support directories, like new subdirs in the sites folder as moshe pointed out above...
Certainly, it's still a can of worms, and a lot of added complication for questionable value, which is why I'm leaning against supporting files (or directories), but I'm still open to a good argument to the contrary.
KISS
I'm a fan of tidy organization. I'd say the length of the pro and con lists answers this for us. If the biggest advantage of allowing profile authors to put any file anywhere is that they can give higher billing to a README file, then lock it down and be done with it. There's nothing stopping the profile maintainer from integrating the readme file into the install wizard pages, and can even pull directly from the README file in the profile's directory. That's even higher billing than moving files around willy nilly.
Yep, agree with all that.
Yep, agree with all that. hook_help, the installers, project/release pages and the Handbook are there for a reason :)
Agreed
This would be yet another break in the put everything in the sites directory rule leaving it wide open for massively different installations that don't work together nicely.
"distrib" directory
Couldn't we simply allow a profiles/[foo]/distrib directory (or similar name) to support this?
For example, a file in
profiles/foo/distrib/sites/all/modules/bar/bar.bazwould be placed into
sites/all/modules/bar/bar.bazby the packaging script after all core and contrib packages were extracted for packaging. This would also allow installation profiles to overwrite certain files of other packages.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Profile maintainers have enough control
Since a profile maintainer can do just about anything they like with their install profile they can put as much 'read me' type information as they like right on the installer page.
And if they want to move files - let them write the code in _profile_final() to do it.
andre