Hi.
Nice module, good I found it!
I'd have to do sth similar myself otherwise.

Very often I don't want to be bothered with hooks, when starting a module. It could be that I want to decide on this later, or maybe I plan to copy the hooks stuff from somewhere else.

Unfortunately, "drush mb" will continue asking me for hook names, until I feed it something. So I go, ok, I give you a "perm", now shut up.

What about just creating an empty *.module file instead?

---------

Btw, about the "perpetual development"..
The benefit of release tags is that people can say "works in 6.x-2.0-unstable1, but does not work in 6.x-2.0-unstable2". This is impossible with the "moving target" of a dev release.
(just saying)

Comments

donquixote’s picture

I should add, it is of course not that much extra work to type that "perm". It just feels clunky.
After all, the drush mb has to beat manually creating the respective files..

joachim’s picture

> Unfortunately, "drush mb" will continue asking me for hook names, until I feed it something. So I go, ok, I give you a "perm", now shut up.

Turn off interactive mode with --noi and it'll write you an empty module file.

> The benefit of release tags is that people can say "works in 6.x-2.0-unstable1, but does not work in 6.x-2.0-unstable2". This is impossible with the "moving target" of a dev release.

I'd have the extra overhead of making releases... and given how development on this project goes I'd easily feel I ought to make a release every few commits. I'd rather people did a git clone rather than download the tarball and then tell me which commit they're at ;)

joachim’s picture

Status: Active » Closed (won't fix)

Wontfix in both cases:

- there's a workaround, using the non-interactive mode (but I'll take a patch if you really want to -- feel free to reopen!)
- this is a developer module, and I recommend the use of a git clone of this module.

joachim’s picture

Issue summary: View changes

make it sound nicer by adding a "just saying".. hmm if this helps?