Module weight in .info

OOooh! Good idea.

+1 on this.

+1 (I found this searching before filing the issue myself)

Moved to D7.

Currently we tell people to do it with an update query: http://drupal.org/node/110238

It's just as easy for Drupal to run that query, and much nicer and cleaner.

There is also a request for Module weight dependencies, but that I think module authors can handle in a hook_install, made a bit easier with being able to see every module's initial setting in .info.

^{benjamin, Agaric Design Collective}

Marking as postponed per Dries comment in http://drupal.org/node/416590#comment-1415226

Marked the following as duplicates of this issue:
#416590: Put weight declaration of modules into a core funtion
#308008: Module weight dependencies

I'd like to bring this back up for consideration. This is potentially an awesome DX feature and it seems like quite a few people (albeit not Dries) are for it.

+1

I'd rather be editing it in the .info than in the database or having to re-install with a hook_enable.

Too late for D7.

Module weights are irrelevant. It's an unnecessary abstraction, the basic idea is that ModuleA must run before ModuleB and this is the information we need to capture rather than some arbitrary number which depends on a vague mutual understanding.

I suggest we add a runs_before or runs_after suggestions in the .info file and generate the weights from this.

Module weight are not irrelevant. I can prove my point, can you prove yours?

Install a fresh install of Drupal 6. Install the shibboleth authentication module. Take a look here: http://drupal.org/node/627958 You can see how I can just set the weight and fix the problem. Perhaps, there was some deeper underlying problem that should be solved, but setting the module weight in the database was one way to solve that problem.

Either way, module weight plays a role in the order of calls. Why would you abstract it out to runs_before or runs_after when that is exactly what module weight sets? 0 comes before 1, etc.

shib_auth.info:
runs_before[] = boost

So what you are proposing, is that if I have 5 modules I need to run before, I need to hack the contributed module's .info file and set a runs_before on each one, as opposed to just setting the weight once, in one place, in the databse, not the code, and having the issue dealt with? Then, if a change is required, you can make the change in the database instead of hacking a module. It's much easier for a module developer to figure out where they need to be relative to what's out there, set it once, and be done.

This isn't to say that we can't have a runs_before or runs_after in the .info file, but that should not be any reason to rid core of module weights. Instead, runs_before as you propose could be a weight setter. Still I'd propose, keep module weight, and set module weight in .info just as one would expect

module_weight = -1

you can use http://drupal.org/project/util to customise module weights?

nowarninglabel, did you even read what I wrote?

I suggest we add a runs_before or runs_after suggestions in the .info file and generate the weights from this.

Yes, you wrote "Module weights are irrelevant. It's an unnecessary abstraction." That is the part I am disagreeing with.

I agree with your proposal of adding a runs_before/after which generates the weights.

If you agree with adding runs_before/after then you also agree with module weights being irrelevant and an unnecessary abstraction.

Internally, Drupal will use the generated module weights to sequence loading and hook utilisation. Externally, packages need to specify only which modules they need to run before or after, because that's the only purpose of module weights.

Clearly, you're not quite getting it, so let me spell it out for you in intricate detail: You wrote:

> Yes, you wrote "Module weights are irrelevant. It's an unnecessary abstraction." That is the part I am disagreeing with.

1. Having a defined weight per module IS an abstraction. It's abstracting the core purpose, which is having ModuleA run before ModuleB.
2. It's an unnecessary abstraction, because under the proposal Drupal can generate the module weights reliably on install/enable.
2. It's irrelevant to both developers and end users. End users don't care about module weights, they just want stuff to work. It's irrelevant to developers, because fixing a break is as easy as specifying which module is causing the problem. Even better, it's self-descriptive, and it's fixed in code meaning a local patch can be tracked using patch_manager.

QED. Stop arguing.

I'm not arguing, I'm making the same valid point I made already which is that they are not irrelevant for the reasons I explained above. I stated why I do not believe they are irrelevant, even if you consider them an abstraction.

I agree though that issue queues should not be filled with back and forths. I made my points above, and hopefully others will fill in how they feel on the issue and thus the community can come to a consensus.

IMMO, module weight is the typical 1990 way to do ordering and yes aidanlis is right, it's an abstraction regardless how you dice it.

However, runs_before[] or runs_after[] doesn't necessarily solve the ordering - in fact it might introduce contradictions, I.E.:
if ModuleA has run_after[] = ModuleB at the same time, ModuleB has runs_after[] = ModuleA, how should Drupal decide who runs first?

To put module_weight = x in .info file is no different than the current Drupal approach, except that it's mutable now and if the weight gets changed during a uninstall / reinstall cycle, you are getting unexpected results. Not good.

What might seem to be a solid approach is to have a table to store the execution order and then has an admin menu to use the drag and drop to oder enabled modules from that interface; in the end, you are solving the execution ordering at the same time encapsulate the underlying order number - be whatever you call it, module weight, sequence number, order position etc. And if you really want, take that table's primary key, which should an int, as that the weight. Again, it doesn't really matter as long as the order is in place, which is the module weight is all about.

Ye your idea means that every module someone installs, they also have to manually set the modules weight on some administration page. That's a terrible pain in the arse, and doesn't solve any of the other problems you mention.

In regards to runs_before and runs_after circular reference; that would be a bug in one of the modules, and like any other bug would require fixing.

A UI for ordering module weights could easily be implemented in a contributed module, but it doesn't belong in core because ideally no-one should ever have to use it.

aidanlis: no, you don't have to manually set the module weight. It's an optional param. If you leave it out, it will let Drupal to decide, be it a zero or one or any number, it's no different than status quo.

Re: runs_before and runs_after circular reference
=> No, it's not a bug that every module developer should tackle, it's a design flaw we should avoid in the first place.

To pre-determine module installation order for a number of freshly downloaded modules(no systems table entries present) when there are cascading dependencies (e.g. Module A depends on Module B which in turn depends on Module C) is crucial. Because if Drupal installs them randomly or not following the dependence order, some module's installation would fail.

Maybe there are better ways to manage all that, but I haven't seen a good approach yet.

Stop mixing dependencies and weight. They are completely unrelated.

Drupal does respect dependencies and is able to build a proper dependency graph and a decent installation / upgrade sequence. Weight is something else entirely, it determines the order of execution of hooks, and should probably be per-hook.

+1 for per-hook.

per-hook is a pretty huge change, how would a module specify weights per-hook?

+1 to #19, a little research shows though, that perhaps this already available?

It was originally a feature request here: http://drupal.org/node/195275

And it was implemented in a somewhat different form here: http://drupal.org/node/692950

+1 for per-hook; for complex develoments having only one weight per module is a really challange and forces sometimes to split modules to get more felxibility

As nowarninglabel noted in #23, setting weights per-hook is already possible in Drupal 7 with hook_module_implements_alter. That definitely does not belong in an info file.

Nor is this issue about changing from the weight system to some concept of runs before or after, which would have to be worked out in a separate issue.

This is a very simple developer experience issue for D8: the ability to set a module's weight without writing a special database call in its implementation of hook_install().

There is a patch in #416590: Put weight declaration of modules into a core funtion that is very likely in large part still good.

Note also from that issue (as Dave Reid noted here in #3) that Dries has to be convinced that this is a great convenience or a matter of describing a module, not configuring it. As it is not supposed to be configured, and resides in the {system} table with other values pulled from .info, i think there's a pretty good case it is part of describing the module.

Simple. Just happened to implement that for another issue.

Tagging

Why was the Needs Documentation tag added to this issue? It's helpful if you can add a comment when you add a tag that is tracked by the Documentation, Accessibility, etc. groups. In this case, it would be good to explain exactly what needs documentation, and where you think the doc should be added.

Re #28, my bad. The module developer's guide will need to include that weight can be defined in .info files. For example, the D8 version of Writing .info files will need this documented.
I can't think of anywhere in the API docs that would need to be updated. The example modules may want to include this as well, I guess that would require a separate issue under their queue if its necessary.

Thanks! We will have to note this in the Change Notice node, once we get those up and running for D8, and once this issue is resolved. Tagging appropriately for now...

subscribe

+1 (no time to review this until next weekend)

Although I support this idea as it removes a hack in hook_install(), I'd like to see a handbook page on what is an appropriate weight for a module. The document should outline the various levels and their purposes.

Rather than sound off here I should follow up on @sun's comment on IRC "skwashd: write it? :P" :)

Subscribe

Removing 'needs' tags so they can be added after commit instead.

I tested locally and seems to work fine. We should probably add something in a test somewhere for this? or assume if the installer is rewritten as planned it will come to use this? If so I'll link this issue there and make sure it gets done.

Just a wild thought, would a hook_system_list_alter(), or a hook_module_list_alter() be an option so that there's no need for weight, runs_before or runs_after? In D7 cache_bootstrap contains a cached version of this list.

I know that it might seem a bit of a chicken-egg thing, the calling order of the hook_system_list_alter() might change at first, but might work as long as the alter is allowed prior to storing it in cache?

Is the desired outcome of this to allow ordered module hook calls? I'd rather take the #1509164: Use Symfony EventDispatcher for hook system route, as events allow such a thing.

Although I didn't see any code that proves that events can handle run_before/run_after at all yet, I agree that this entire weight pattern is utter nonsense for a modular system like Drupal, and I'd rather get rid of it entirely.

Note: The hard-coded weights are the direct equivalent of the event listener/subscriber weights in Symfony, which are equally hard-coded.

@sun there's a lot of things in Drupal that are nonsensical and don't get the same kind of treatment in the issue queue, I think this is a legitimate request to resolve situations that have no clear way out and should be re-opened

I agree this would be great idea. There are situation we need to change module weight, I have it now with cookies, see: https://www.drupal.org/project/cookie_content_blocker/issues/3203376#com...
I would love to reopen it. And it would be great to have the possibility to change the module weight if necessary in .info !