dependency system: package descriptors

PHP'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:

$theme = <<<DOC
// Comments are supported
  // with single-line PHP syntax

Key:Value pairs
With: Spaces
On :Either
Side : Work like you expect them to // with comments at the end too

Double-Quotes : "Can be used to \"surround\" a value"
And are : "needed to use two slashes inside a value // like this"
Double-Quotes : are returned as part of the value " when not at the beginning "

Single-Quotes : 'Can be used to \'surround\' a value'
And are : 'needed to use two slashes inside a value // like this'
Single-Quotes : are returned as part of the value ' when not at the beginning '

Multi-line values: "Are supported when you use quotes
to surround them."

The value:
can be placed on the next line too

This works: 
"For multi-line
values as well."

DOC;

if (preg_match_all('@^\s*((?:[^:/]|/(?!/))+?)\s*:\s*(?:("(?:[^"]|(?<=\\\\)")*")|(\'(?:[^\']|(?<=\\\\)\')*\')|([^\n]*?))\s*($|//)@ms', $theme, $matches, PREG_SET_ORDER)) {
  foreach ($matches as $match) {
    list(, $key, $value1, $value2, $value3) = $match;
    $value = stripslashes(trim($value1, '"')) . stripslashes(trim($value2, "'")) . $value3;
    print("$key => $value\n");
  }
}

Why package.ini and not modulename.ini?

The "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?

The "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?

This 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.

Eventually 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.

A 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.

Sorry 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;
}

spidey: 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.

Morbus Iff: Thanks for the explaination. I knew that I was missing something.

How much of this is generated automatically, and how much by hand?

At 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.