I am very honored to be granted the privilege of taking the lead on the module packaging and dependency system. After collaborating with Adrian and acquainting myself with past discussions and work already contributed, I'm very excited to get this functionality in place. Without your support we will not be successful so I urge you to please give feedback and suggestions and most of all your support so that we can speed this contribution up to completion.
You can visit the following links if you want to familiarise yourself with where we are at today.
http://drupal.org/install-system-overview - Adrian's initial overview of the install system.
http://drupal.org/node/34198 - Link from dikini (Vlado) about his presentation at DrupalCON.
http://dikini.net/node/46 - The presentation and notes.
http://dikini.net/tags/drpkg - drpkg tag
http://lists.drupal.org/pipermail/development/2006-July/017908.html - latest discussion on drupal_dev
Focus: This task is only focusing on package descriptors. The layout and content of the file which will define a module's meta data and its dependencies.
Outcome: The successful outcome of this task is an agreed upon standardisation of package descriptor files; what these files look like, where they are stored, their content, etc. and generated with as much information as we can possibly obtain patched to the repositories.
This is the first step in getting the dependency system in place and if we take the whole project in smaller bite sized chunks to chew on and digest it will aid in keeping it simple and easier to stay focused and finalise as soon as possible.
You are still encouraged to continue posting ideas and comments that you may have regarding the dependency system, packaging, post installation process, updating process, module administration, module loading process or anything related on drupal_dev and the relevant forums, we will be paying attention to these and your information will aid in streamlining this project so that we can complete the outstanding tasks before code freeze.
Current assumptions:
We have decided to use the .ini file format as php has built in support for parsing these.
Each module is placed in its own directory and has a package.ini file as descriptor.
By using a modified subset of the drpkg subsystem files are being generated as initial descriptors for modules.
Generated content:
module name (from module file)
repository (contrib,core)
description (hook_help admin/modules#description)
path (directory on repository)
dependencies (module namespace in function names)
Questions:
How are we going to describe themes?
Any advice on obtaining more dynamic information from current modules?
Any meta data that should be added to the descriptors?
Any meta data that should be removed from the descriptors?
Examples of a few package.ini files are attached for your review. We are looking forward to your suggestions and feedback.
Nick
Comment | File | Size | Author |
---|---|---|---|
#11 | meta.tar.gz | 2.42 KB | nickl |
descriptor.tar.tgz | 748 bytes | nickl |
Comments
Comment #1
Steven CreditAttribution: Steven commentedPHP's ini parsing functions contains way too much voodoo magic and hidden syntaxes. PHP constants are filled in, various keywords are replaced (e.g. 'yes', 'on', ...), keywords are reserved and even boolean expressions are evaluated. On the other hand, PHP's ini syntax is restrictive. According to the docs, all values containing "non-alphanumeric characters" must be surrounded by quotes.
Judging from the example files, the idea is to put varied content in the ini fields including pieces of text. INI files as defined by PHP are not suitable for this as they have no support for multi-line values.
Why not just use our own format? I propose the following... no hidden replacements, a much more forgiving syntax when it comes to quotes, newlines and spaces, and support for multi-line values:
Comment #2
Morbus IffWhy package.ini and not modulename.ini?
Comment #3
Morbus IffThe "repository" seems like a useless bit of info, especially when it's controlled by the user. Can't we just whitelist, instead, all of the core modules, and assume everything else is contrib? That seems the smartest way to save space and logic, otherwise we're gonna have data duplication across all of contrib (stating that yes, modules in contrib, are, um, in contrib).
Also, I'll throw another vote out for disliking .ini files.
How are we handling translations?
Comment #4
Morbus IffThe "maintainer" name could be inferred from the owner of the project, again making this another bit of housekeeping that we don't need to keep in the .ini files - look up the "path" in the drupal.org database, find the project that matches that path, and suck out the maintainer from the owner of the project. Downsides: assumes all modules have a project (which, in the case of some of mine, don't), and assumes that Drupal.org usernames are "good enough".
I'm presuming the "size" and "MD5" would be autogenerated by the cvs packaging script?
I'm not sure I like "installnotes" - are we replacing the stronger INSTALL.txt?
Can't "path" be autogenerated by the cvs packaging script too?
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedThis issue is related to http://drupal.org/node/76340 where I've been working on UI redesign.
The UI is dependent on the layer beneath it, particularly in how things are implemented. I've successfully implemented a simple dependency system already.
Comment #6
joe.murray CreditAttribution: joe.murray commentedEventually we want to be able to identify contrib modules that play nice together, and those that don't. Often those responsible for modules know that already for other popular contrib modules. Letting module maintainers state some this early on would be useful - at least warnings could be generated when building an install known to not work, and a format could be established that would later allow more automated test suites to state modules have been verified as working together to a certain standard.
Comment #7
pwolanin CreditAttribution: pwolanin commentedA question about the initial description:
"dependencies (module namespace in function names)"
Does this mean trying to guess modules based on function names, or will there be some grand mapping of all function names (in core and contrib) to their containing module?
Such a mapping actually might be useful to find modules that are incompatible because of (inadvertant) use of the same function names.
Comment #8
gopherspidey CreditAttribution: gopherspidey commentedSorry if this has been answered or discussed in the past, but why are ini files used.
Why don't we just have a _meta function in the the .install file that returns an array of terms. Then we don't have to read and parse the file manually, we just call the function when we want the information.
So thing simple like this.
function drupal_meta () {
$ret = array();
$ret['repository'] = 'core';
$ret['maintainer'] = 'maintainer name';
......
return $ret;
}
Comment #9
Morbus Iffspidey: in a nutshell, the .ini files would be parsed and read as part of drupal.org, and executing arbitrary PHP in hundreds of contrib modules on a production website which serves as a developer forge is not safe in any way, shape, or form.
Comment #10
gopherspidey CreditAttribution: gopherspidey commentedMorbus Iff: Thanks for the explaination. I knew that I was missing something.
Comment #11
nickl CreditAttribution: nickl commentedThank you for all the comments and feedback.
We have progress:
We've implimented Steven's parser and the file format currently looks like this:
This is the minimum content as implimented on the admin modules screen. You are still welcome to suggest any additions to this file and to see them in operation by following this thread: http://drupal.org/node/76340
Module descriptors are stored in their module directories as modulename.meta.
Attached are a few meta descriptors needed to test the current admin modules screen patch.
Please don't hesitate to make more comments your input is valued and appreciated.
Comment #12
pwolanin CreditAttribution: pwolanin commentedHow much of this is generated automatically, and how much by hand?
Comment #13
merlinofchaos CreditAttribution: merlinofchaos commentedAt the moment, the entire .meta file needs to be generated by hand. There are 2 reasons for this.
1) Automatic generation of some of this data is tricky and would be quite a bit of code AND
2) project.module has other things that need to happen before any of this can be done. WHich means
3) manual generation of the .meta file is currently the best way to get improvements into 4.8.
Comment #14
nickl CreditAttribution: nickl commentedDone and comitted to head : http://drupal.org/node/80952