enabled_modules vs used_modules vs views_system... merge? deprecate? [#1161806]

hey

there's a nice module around, its called Views System.
reportedly it does the same as enabled_modules and yet, more.
there's also the older Used modules

merge the modules?
deprecate in favor of Views System?
efforts could be in for just 1 module, with all the devs united for that goal.

please explain why that should not happen, if you don't agree

Comments

Comment #1

mlncn CreditAttribution: mlncn commented 18 May 2011 at 23:07

Status:

Active

» Postponed (maintainer needs more info)

Waiting for comparison of features per #963418: merge enabled_modules into views_system.

Comment #2

lpalgarvio CreditAttribution: lpalgarvio commented 22 June 2011 at 12:45

Issue tags:

+views

+1
worked a bit on views_system: provided comparisons and created default views for views_system

Comment #3

juliangb CreditAttribution: juliangb commented 27 June 2011 at 14:22

Status:

Postponed (maintainer needs more info)

» Active

There hasn't really been the discussion I was hoping for on the Views System issue (#963418: merge enabled_modules into views_system). I was hoping that we could compare what each project does best and have a chip in on what functionality is best suited to each project. Instead, it appears that Views System is just going to pick and choose bits of functionality to duplicate.

Thus, for this issue (and for the enabled_modules project), there needs to be a decision on how to take this forward. I see a few options:
1) Continue as previously and ignore Views System. IMO, this is duplication and would waste our time and confuse users.
2) Continue, but have a deliberate focus so that there is some differentiation. For this, we would need to understand which bits of Enabled Modules are not being addressed by Views System. It would also be useful if going down this route of having some agreement with the maintainer of Views System in order that each module keeps a differentiated role.
3) Deprecate (either totally or for Drupal 7 core onwards), and push users towards Views System. We might be able to aid development there. Also, if we suggest this, are we really suggesting that all existing users switch? This seems a bit silly considering Enabled Modules currently has 372 reported uses, Views System has 89.

As might be clear by my descriptions, I think that Enabled Modules has to take account of the other modules in some sense, which would mean option 2 or 3.

It'd be really great to have a discussion / comments on what the best options seem to be so that we can come to a consensus that is best for the long run.

Comment #4

lpalgarvio CreditAttribution: lpalgarvio commented 27 June 2011 at 14:53

i agree with you on some points
IMO it would be best to do a merge and deprecate enabled_modules for both D6 and D7.
maybe a comparision at code level is what should follow next...

there has to be more communication and cooperation though.
try asking for co-maintainship of views_system

in keeping in sake for the enable_modules to views_system path, i submitted default views for D6 and D7 version, imitating much of enabled_modules own views.
the author didn't like them though.

i'll make new versions of the views and explain why it would be good to have something very similar to enabled_modules.

Comment #5

juliangb CreditAttribution: juliangb commented 28 June 2011 at 12:26

There is another key question that I think we should think about too. What is the key aim of each project?

I think for enabled modules, there are two key features:
- Provide a basic list of enabled modules that can be used as a basis for a "How did I build this site" type page
- Provides several pages ("advanced lists") for a site admin to see which modules are enabled, disabled, and those modules that are listed in the database but that code has been removed.

Enabled modules has tended to stick with modules rather than themes/profiles, and the views support has been a means to an end rather than being a direct aim of the module.

I think that Views System's primary aim is to provide the views support, with any default views being more of a sample rather than the aim of the module.