Hi,
I think it would be nice to be able to disable the contribs only via a simple drush_mm command.
I wrote a working and tested prototype in bash (
attached at http://drupal.org/node/348914 - Drush MM docs page.
direct link - http://drupal.org/files/drlist_contribs.sh_.txt ) - it lists only enabled contribs - so it is easy to do a
drush mm disable/enable on its output...
What steps do we need to get a list-contribs command?
Am I welcome to do that?
Comments
Comment #1
clemens.tolboomI guess I could change the behaviour of
drush mm listby either adding a param sodrush mm list enabledcould work or just when in --verbose mode list all modules.Please give some feedback :-)
Comment #2
rsvelko commentedI spent some time thinking on the smartest (both in user experience and code-elegance) way to do this, so here it is:
1. I modified the _drush_mm_list_modules function: (have not touched the 'list' array - cause it may be used somewhere else and I did not wish to mess with it )
so now the func is : (diff below, after it)
And a diff:
And the output as of now:
Mark the last part... enabled contribs are listed and a little help text printed... The text is meant for clemens to read and understand where I am taking us... It can be removed from the listing function...
As I see it just a list of enabled and disabled is not so important to the user of drush_mm.
A more interesting thing is
- "Is content_access enabled"
- or even "Is that 'access' or something module enabled?"
- or the usual 6.x->6.y question "How on earth am I supposed to disable and then re-enable those 30+ modules scattered acrross my admin/build/modules page ?!? "
So I propose we show the user enabled contribs (and maybe disabled?) by default and a wildcard capable per package/project listing on demand - as an additional argument to drush mm list (see echo-ed help text above )
That should do it all!
Opinions?
Greets.
Vladimir, Rousse, Bulgaria (and Vienna, Austria).
Comment #3
rsvelko commentedThis way it will be an intuitive command - no additional complicated syntax.
Comment #4
rsvelko commentedthe part with listing contribs is done by me above. What about the other features - how would we extend mm list ? Where to look at and how to do it most gracefully? Clemens?
Comment #5
clemens.tolboomGreat work ... Nicely documented ... hope to implement this soon.
Comment #6
rsvelko commentedSome progress on that ?
If you have some 1-2 hours these days we can make a mini "over the web" sprint? I am available at every time/hour in the next 5 days - email me via contact form if interested.
Comment #7
clemens.tolboomI'd love to spent some time on your improvements ... hope to find it :(
I'm most of the time on irc so we could chat a little. And maybe solve this nice improvement :)
Comment #8
clemens.tolboomJust another note: As I'm doing drush_sm at the same time where I use subcommands like list export and import maybe we could use export and import for this improvement?
Comment #9
clemens.tolboomJust a note ... the filtering on Core modules is as simple as checking the module path DRUPAL_ROOT/modules right?
I have to check this with drush but maybe a switch like --skip-core would do the interfacing
Comment #10
clemens.tolboomIn adapting drush_sm to the latest version of drush 2.x I introduced some parameters and an option.
For this issue I will introduce a few options and parameters
--skip-core
--package=devel ?
and parameters?
Do we need more?
Comment #11
rsvelko commentedThere are 2 tasks here:
1. --skip-core
2. list all modules that belong to a certain project/package (I forgot the difference between the two if any) or are named "devel" for example...
So - 1. is solved with this option introduced
and 2. - with the --package option (my personal opinion is that "drush mm list name" is better than "drush mm list --package name" ... If we write good docs it seems nicer(=shorter). )
Comment #12
rsvelko commentedabout 2. - I need a wildcard implied by default - like bash's grep
so "eve" would match devel for example... with no need to write "*eve*" ...
Comment #13
puya commentedSo, is this functionality (listing enabled contrib modules) committed to drush_mm or drush_sm or drush itself? or is it still a script?
Comment #14
clemens.tolboomThis feature is on my time restricted list of tasks ... so in the near future for drush_mm :)
Comment #15
clemens.tolboomHmmm ... I somehow missed that all info is at hand.
So for now I have to fiddle out how those args work.
Comment #16
puya commentedsubscribing
Comment #17
clemens.tolboomThe module became obsolete for drupal 7. See project page for the reasons why.
drush has this nice command
drush pml --no-core --status=enabled