provide a project meta information file

subscribing

This is a really good idea. This way the module page would have only extra grouping when needed as well. I mean, in the latest mockup for the new module page, we introduced the 'package' groups inside the 'new', 'enabled', 'disabled' groups. I got a lot of bad responses about that, and this patch would give us the possibility to only group the parts that *really* need to be grouped.

Are there user cases in which there's 'projects' don't have a 'main' module on which the other ones are depending? If this is never the case, why not just use the .info file for it? Just throwing thoughts here....

Plus one :-)

Okay, this patch doesn't really do anything, simply copied the code for loading module info files into one for loading projects. I think the implementation of this will depend a lot on the new UI of the modules page. On the plugin manager, it is more clear.

I've called the new file project.info. Here is my reasoning:

You should be able to ascertain that a given directory contains a Drupal project, what that project is called and what type of project it is.

For the sake of consistently, and because many modules do not want to have a module with the same name as the project, I thought it made sense to not try to cram everything into $module.info. These two files (project.info and coder.info) have different purposes, and different schema.

If we want, we can call it coder.project or something, but I thought using a semi-standard naming convention would save effort.

Here is an example project.info for coder:

;// $Id$
name = Code Review
type = Module
description = Developer Module that assists with code review and version upgrade
default_modules[] = coder
default_modules[] = coder_review

I would much rather have the project follow the sort of layout as below:

File Struct:
Project[i] -> modules[ii]->normal layout that exists now

In organizationally i think something like allowing defined types

name = developer suite
type = Project
description = Developer Project that assists with code review and version upgrade
modules[required] = coder
modules[required] = coder_review
modules[required] = devel
modules[themer] = themer
modules[themer] = 'other optional theme dev modules'

The ideal here is you can combine several different sets of modules together in what some would normally do already then inside of the module page you can click either just required, or Required and Themes or Required Themes and Modules, etc. Enabling the corresponding modules. These modules can be listed on the project's entry on the normal modules list page. For more detailed control we could have the project title as a link to a Project Config page, which would allow you to then override the defaults and enable/disable modules per module basis.

Chris and I talked. For now, I recommend we keep it simple, although his approach is very cool, he was thinking more in lines of mini-install profiles. He's actually looking for something more like "Features", which I sent him towards.

I'm very open to changing the conf file schema if people are interested, but prefer to not overcomplicate or "build for the future" at this moment.

Yeah, definitely agree that the scope of this should remain basically just informing Drupal core about stuff Drupal.org knows, and enables the plugin manager/modules page to make intelligent decisions about which modules to enable by default and some other stuff. It kinda sucks though that module developers have to type this ... one .info file is annoying enough, let alone two. :P

We've kicked around a variety of approaches...

1. Using Update Status module to provide this information as it does on admin/reports/update. Relies on connectivity to Drupal.org, and doesn't work for custom modules. Bleh.

2. Use the packaging system to either programmatically create the .info file, or move some of these properties into the existing .info file, so the only thing the module maintainer needs to define are the default_modules[] parts that require a human being to make a decision. Problem is not all of these things are able to be programmatically derived.

3. I forget now. Sorry, I'm really tired. ;P

So I think this needs more discussion, preferably from people like Derek Wright, Earl Miles, etc.

1) This will mess up with project.info in project module. Suggest projectname.project.info instead.
2) This should tie into the idea of projects that update.module is already using. It knows what project modules belong to. This meta data can provide more information about those projects. That could and absolutely should tie into update.module, at a minimum, and almost certainly the modules page because the current UX modeling really wants to be able to do more module <--> project defining. This is a good thing. Implementing 1) above can make views.project.info properly match the actual project name.

Agree w/ Merlin's points. Here is an updated patch

I'm confused. The doxygen in the latest patch does not match the defaults.

Subscribe.

I do not agree we should use drupal.org information for project descriptions. If we go that way, it is an easy step for using that information for all modules descriptions in .info files, which is a complete other issue. This issue is about providing meta information for projects, thus bundles of modules, which have or have not a main module. It's a pity each module is called a project as well on d.o., so it's a bit confusing.

Is it possible to require project maintainers to rewrite their project structure in the following way?

/project_foo/
/project_foo/project_foo.info <--The project info file
/project_foo/project_foo/
/project_foo/project_foo/project_foo.info <-- The module info file
/project_foo/project_foo/project_foo.module
/project_foo/project_foo/project_foo.install
/project_foo/module_bar/
/project_foo/module_bar/module_bar.info
/project_foo/module_bar/module_bar.module
/project_foo/module_bar/module_bar.install

Or is this a complete CVS nightmare?

Subscribe.

How do we represent that some modules live outside of drupal.org? update module already supports this.

Even though it does cause some cvs headache, i do think it is OK to require proper filesystem hierarchy for submodules. If the benefits are great.

I'm fairly ambivalent about the module subdir thing, although it does seem like a logical improvement to readability, I can't see any good reason not to do it. Especially, if we make project.info obligatory and everyone has to mess with their modules anyways.

A slight correction: #538660: Move update manager upgrade process into new authorize.php file (and make it actually work) doesn't actually require project.info, just looks for it, and uses it if it exists.

Best,
Jacob

I do not like the forced organization. I do not believe that it is at all necessary.

I've just recently returned from being offline for two weeks and trying to catch up on a huge pile of emails and issues. I've only briefly skimmed this issue and patch. On first glance, I'm confused.

Each module's .info file already says the project that module belongs to (either via a packaging script, or via CVS Deploy). This is how update.module can do the grouping. If that's the case, what do we *really* need a separate project-wide metadata file for?

If you want to clean up the modules page in the admin UI, do the same thing update.module does. This does *NOT* require connectivity with drupal.org. update.module just looks at data that's in the .info files already (or data that's altered and put there by cvs_deploy).

If you want to know what project to download to satisfy a given dependency, you need all the metadata for all projects anyway, and in that case, you probably need to be using Adrian's YAML stuff -- you need a full DB of all modules and projects. I don't see how a per-project metadata file (on its own) helps this problem.

All this recommended/suggested/required/optional stuff is misplaced. That belongs in each module's own .info files via #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files #188038: module info file: recommended modules et al.

My inclination is to call this "won't fix", but I'm willing to hear counter arguments first.

However, if a patch like this is committed for some reason, I think it's confusing and weird that the project-metadata alter hook is also called hook_system_info_alter. That seems like a major DX WTF to me. How do you know if you're altering module or project metadata (especially if the key is the same in most cases)? Ugh.

p.s. Requiring a specific directory layout seems like a *terrible* idea with *no* benefit. ;) Please let us not waste any more time considering that option...

I'm on vacation, so this will be my last post here most likely. I'm fairly ambivalent, however, a few things to consider:

1. I already see this post getting emotional. There isn't time for that, let's please try to back up statements with reasons and not just say it is terrible, awful, stupid, useless, etc.

2. The modules page is broken because user's cannot understand the module descriptions and their relations. Modules are split mainly for technical reasons, which non-technical people don't get. There is a lot of value in having a "Check one box and a get a product" type approach. Features is doing something similar, but even with the modules page, this is the only way to fix it AFAICT. Offering them a list will not help that problem and will force us to write more UI. I don't see how this solves the problem.

3. For the Plugin Manager, see #2. My original suggestion (and what the PM currently supports) is an option project spec file, and if you don't provide one, it will just try to enable the default module. This is still okay I suppose.

4. For the future of Drupal and modules, we need to support everything we need without hitting d.o. This is crucial of all packaging formats. It cannot be dependant on a single repo. I think we can all agree on that.

5. rpm, deb, etc all have a package spec file. I'm not saying 100% that we need one, but hey, just saying... They obviously see some value in it.

This issue calls into question a big debate in the drupal community: Are modules libraries or products, for that matter, is Drupal a library or a product. I would like to think that modules are libraries for the most part, and become a product when in a package. Further, we aren't just talking about modules, and it is important to remember that. Until something like Features is part of core, if we expect core to be usable on its own, we need to shorten the modules page and make it more end user friendly. Does anyone have any other ideas on how to do this?

Best,
Jacob