The development-modules directory is populated, but they are not included anywhere. They should probably not be enabled by default, but at least available.
New platforms should have a sites/all/modules directory that symlinks back to workspace/development-modules.

Marked as minor because this functionality is icing.

CommentFileSizeAuthor
#6 drubuntu.development_modules-1013194-6.patch1.58 KBGrayside
#4 drubuntu.1013194-4.patch1.64 KBGrayside
#3 drubuntu.1013194.patch864 bytesGrayside

Comments

owen barton’s picture

owen barton commented

Indeed - this stuff is still in progress. I am wondering if we should symlink everything - perhaps that would create a lot of cruft on module pages? I was thinking of something like a drubuntu-dev-enable (de) command that would symlink and enable modules in each priority automatically. Run without parameters it would do P1 modules, you would also take a "2" or "3" argument, to do those groups. We could then add a "development-modules-' . $core . '-p' . $priority" option (to compliment the development-projects one), that would default to empty. If this option is empty the de command would scan the appropriate directory and enable all modules present, however users could also specify a subset of the modules in that directory that they want auto-enabled by default, giving a finer degree of control.

How does that sound?

Grayside’s picture

Grayside commented

That sounds good. Anyone using drubuntu probably doesn't mind module page cruft very much. Let's track the simple piece of symlinking in this issue, and continue talking about module sets and drush commands in #1013192: Better Groupings/Group Names for Developer Modules.

Grayside’s picture

Grayside commented
Status: Active » Needs work
StatusFileSize
new drubuntu.1013194.patch864 bytes

This works, however it does not target a major version of Drupal within the development-modules directory. Not quite sure what the most efficient and non-redundant way to do that would be.

Grayside’s picture

Grayside commented
Assigned: Unassigned » Grayside
Status: Needs work » Needs review
StatusFileSize
new drubuntu.1013194-4.patch1.64 KB

Now symlinking for the correct major Drupal version.

Grayside’s picture

Grayside commented

Upon further thought, linking the development modules into sites/all/modules creates potential conflict with using installation profiles that place modules under the /profiles directory. For example, a given version of OpenAtrium will be dependent on a certain version of ctools.

The options then are to use only those modules that are most generally useful or developer-centric, or to link the modules in such a way that profile-distributed modules are not ignored.

The only thing that I can think of is to place the link not in sites/all/modules, but directly in the core modules directory.

This could also be fixed by allowing the linking in of development modules to be controlled by the dsa command. That sounds like a good option either way, but I think it's counter to the goals of the command to require that kind of forethought.

Grayside’s picture

Grayside commented
StatusFileSize
new drubuntu.development_modules-1013194-6.patch1.58 KB

Here's that patch.