Posted by dww on November 27, 2007 at 11:52pm
.info
78% (29 votes)
.pkg
19% (7 votes)
other (please comment with your idea)
3% (1 vote)
Total votes: 37
What should the suffix be for the files that installation profile maintainers use to define the packaging?
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.
What should the suffix be for the files that installation profile maintainers use to define the packaging?
Arguments in favor of .info:
Arguments in favor of .pkg:
Part of my drupal 7 workload
one of the first things i intend to do for drupal 7, is to turn profiles into a special case of modules.
Where the profile is always loaded.
This is intended to work around the problem of always requiring a _support module.
Naming them .pkg would cause unnecessary code duplication.
--
The future is so Bryght, I have to wear shades.
It's not duplicate if they're totally different attribute sets
I'm not convinced .pkg is a good idea yet, but just to clarify:
The attributes the packaging script reads and cares about are totally different from whatever attributes the installer will read and care about, if/when the installer ever parses a .info file. For example, the "dependencies" attribute in module .info files is on the granularity of modules, and includes no version information at all. The "packaging" attribute (or whatever we call it) is on the granularity of projects (which might contain multiple modules) and has to include version information, as well. Even if we introduce version-specific module dependencies in core someday, that's still going to be per-module, not per-project. So, there's really no chance we're ever going to actually share the same code. There will be a set of attributes the installer/core cares about, and a separate set of attributes (really, 1 big attribute) that the packaging script cares about. Whether or not these distinct sets are in different parts of the same file or different files isn't a fundamental question, and since the attributes will probably never be shared, there's no "code duplication" either way.
Why no duplication?
I'm not sure why you say there will never be duplication. Why would "this install profile requires Views 1.6" differ from "this module requires Views 1.6"? Or is it because modules may need to specify a version range?
Either way, I think I favor using .info files simply to avoid inventing more extensions or, god forbid, syntax.
projects vs. modules, and version information
packaging (and update_status, for that matter) operate on projects. like http://drupal.org/project/views
each project can include 1 or more modules. for example, the views project includes the following modules: views, views_ui, views_rss, and views_theme_wizard.
core's module dependencies operate on modules. so, for example, the organic groups module (as far as the core modules page is concerned) depends on views and views_rss, but not views_ui...
i know it's a little confusing for the uninitiated, but this is a critically important distinction. neither the packaging script nor update_status can know exactly what files inside a given project belong to a given module. so, an installation profile that needs to include just views and views_rss, but not views_ui, is utterly screwed. the best it can do is include everything in the "views" project (i.e. what you get when you do a "cvs co -r [tag] contributions/modules/views"). similarly, there's no such thing as "a new version of views_ui is out"... all update_status can tell you is when a new version of the entire views project is available, and you don't know if views_ui actually changed at all between versions 5.x-1.5 and 5.x-1.6 (unless you do your own CVS archeology or the release notes tell you). This is the price we pay for including multiple modules inside a given directory and considering the whole thing a "project".
Back to the question at hand: the stuff the packaging script cares about will be a list of project names and their corresponding versions (which can then be directly mapped into CVS export commands, which is exactly how the script will create the appropriate directory tree for the install profile's tarball).
The stuff core's module .info parser cares about is a list of module names, which doesn't (and probably will never) include version information at all.
Therefore, there's no way to share these lists of "dependencies", since they're completely different data. Core wants to know module names (without version) and the packaging script needs to know about project names (including the version).
Therefore, it's not duplicate, since you're listing different things, and it doesn't matter as much if they're in separate files or the same file.
Finally, I should add: I'll stab (repeatedly) the first person to propose the .pkg files should have a different syntax. ;) These are going to use .info file syntax, end of story. Period.
Are we talking about the
Are we talking about the file that will be for the profile in the profile's own directory? If so I would say use the .info because it is not clashing with module .info files, it is on it's own. The system shouldn't be searching for .info files in any of the profiles trees unless you are installing that profile. I don't know of any other use for it, but please correct me if there is.
Core doesn't (yet) read .info files for profiles
I'm talking about a file in the root of the profile's directory in CVS, i.e., right next to the "foo.profile" file, that the packaging script on d.o will parse and act on. Core doesn't (yet) know anything about .info files for install profiles.