Way to download "soft" dependencies [#1833530]

At the moment only modules and themes are downloaded if they are listed in .info files as:

dependencies[] = {modulename}
base theme = {themename}

Though this works pretty good, some modules have "soft" (optional) dependencies.
These dependencies are not listed in info files and not required to enable the module,
but may enhance the modules functionality by being present.

There should be a way to download such dependencies after the sandbox was build.

Proposed solutions:

[very easy] Define a list of "standard" modules, which are often used as dependency and always download them
[easy] Create a custom module which downloads such modules directly (security does not matter much on a simplytest instance)
[moderate] Add a textbox to the simplytest info-bar at the buttom for downloading modules by shortname (triggers a non-drupal php script)
[hard] Implement a complete quake-html-javascript-like drush console which can be opened by pressing [some key]. This would make it possible make use of many drush functionalities.

Comments

Comment #1

patrickd CreditAttribution: patrickd commented 6 November 2012 at 17:08

@Jerad Bitner just made me wondering whether we can't use the standard "Install new module" (admin/modules/install) drupal functionality here.

This would need a way to connect either via SSH or (S)FTP to the server.
The problem here is how to implement this, without opening security wholes on the main test-server.

Comment #2

Deciphered CreditAttribution: Deciphered commented 8 November 2012 at 20:47

I would suggest the use of Makefiles, which is where I generally put my optional integrations (soft dependencies), as that way it allows for any optional libraries as well as optional modules.

Comment #3

patrickd CreditAttribution: patrickd commented 8 November 2012 at 20:53

Yes, makefiles within modules will automatically be executed with drush.

Unfortunately only a very small amount of modules use them, for such.

Thanks for your thoughts :)

Comment #4

Deciphered CreditAttribution: Deciphered commented 8 November 2012 at 21:28

Thinking further on this (after testing Wysiwyg Fields on SimplyTest.me), there could also be a need for specific downloads just for when using the project via SimplyTest.me.

An example is Wysiwyg Fields, or even just Wysiwyg, it makes no sense for either to include a Wysiwyg library in a normal makefile as there are multiple different Wysiwyg libraries supported, but it does make sense for all Wysiwyg libraries to be downloaded when using on SimplyTest.me

Potential solutions:

1. Check for a simplytest.make file in the source project and download anything specified there.
2. Add support for a simplytest tag in a projects .info file (kind of re-inventing the wheel though):

simplytest[module] = ...
simplytest[library] = ...

3. Implement an advanced DrushMake.me like interface for setting up the sandbox.

Sure I could come up with more ideas, but I'm really hoping that the 1st idea (and the 3rd idea) are the ones to go with.

Comment #5

patrickd CreditAttribution: patrickd commented 8 November 2012 at 21:33

I also thought about a special simplytest.make file as optional for modules and distributions (definitely huge impact with few effort),
but this doesn't solve the current problem that only a few modules would make use of this (just like normal makefiles).

Comment #6

Deciphered CreditAttribution: Deciphered commented 8 November 2012 at 21:47

Absolutely, it would only work for those who know about it and wished to take advantage of it, but if a module does not declare it's optional integrations in any standardized way then there's nothing you can do automatically, which is why I'd opt for both 1 and 3, gives the modules that want to add special support for SimplyTest.me the ability to do so, and the ability for the end-user to specify custom additions.

Comment #7

Deciphered CreditAttribution: Deciphered commented 8 November 2012 at 21:50

On this subject, while I'm mainly talking about the ability to have the optional integration modules/libraries/etc downloaded, it would also be nice to have a way to have other modules specifically enabled, such as example features or UI modules.

Views as an example isn't so useful for testing purposes unless the Views UI module is enabled, other modules also follow this trend.

PDF Archive as an example comes with a example feature, as the module is generic and doesn't really do anything out of the box, and it's configuration is 100% rules based, so the example feature would really be the one I want enabled on SimplyTest.me so that people can see the module in action.

Comment #8

patrickd CreditAttribution: patrickd commented 8 November 2012 at 21:56

Ah, http://drushmake.me/ now I see what you mean.

Rather then implementing such interface I'd keep things as simple as possible (the user who wants to test should do as less as possible).
There fore 1+ for a simplytest.me specific make-file

But I still would like to have a very very simple way to add another module,
just kind of a textfield (maybe also here an autocomplete) and a submit button - boom - done ;-)

Comment #9

Deciphered CreditAttribution: Deciphered commented 8 November 2012 at 22:28

From the point prior to install you could have an 'Add another' approach, which would be a way of keeping it simple.

However, I would suspect that a lot of the time people will find that they need another module (or library) after the fact, so yes you would probably want someway of doing so then as well.

Comment #10

marcvangend

he/him

Dutch

Amsterdam

CreditAttribution: marcvangend commented 16 November 2012 at 10:41

Coming here from #1842420: Multiple modules...

I agree with #9, just having a "add another" feature when starting a new build would be great, and I suppose it would suffice for most use cases.

Using the admin/modules/install form would be the obvious way to add modules after creating the site, but I can understand that you worry about security. Perhaps you could slightly alter that form, disabling uploads and restricting it to download from http://ftp.drupal.org/files/projects/ only.

Comment #11

patrickd CreditAttribution: patrickd commented 16 November 2012 at 10:50

Okay, the add another solution on the submission form would be the way to go, but we should at least have it collapsed as "advanced option" to keep everything as simple as possible.

I'm not worried about the admin/modules/install form because I don't know where stuff comes from (anyone can push anything into sandboxes anyway) - but this feature of drupal requires FTP or SSH access to the server where the sandbox is hosted on.
It's pretty easy to make sure that no harmful shell can be executed by PHP, but although every sandbox has it's own unix user, I'm still not convinced that there's some way to break out of that shell-cage.
Also, drupal 6 hasn't got this feature...

I will further concentrate on getting the service stable (making sure 99% of the most used modules work fine, rewriting the dependency resolving system to work with versions, etc..). Afterwards I'll tackle these features

Comment #12

patrickd CreditAttribution: patrickd commented 16 November 2012 at 10:51

uh yes, and I want to add in

test_dependencies[] = {modulename} (see http://drupal.org/node/542202#dependencies)
simplytest_dependencies[] = {modulename}

for resolving

Comment #13

patrickd CreditAttribution: patrickd commented 21 November 2012 at 00:43

Status:

Active

» Fixed

test_dependencies[] = {modulename} (see http://drupal.org/node/542202#dependencies)
simplytest_dependencies[] = {modulename}
simplytest.make

Were committed

As far we can talk about real "soft" dependencies, I think we did out best

I'll create a follow up issue about an advanced interface for optional modules

Comment #14

Deciphered CreditAttribution: Deciphered commented 21 November 2012 at 02:18

I still intend to take a look at the 'add another' approach from #9, but I'll likely put that in a separate issue as it's not specifically about soft dependencies.