Forked module with same .module file breaks testbot

This is a known problem. See #2205271: Project namespace for dependencies which has a patch to Drupal core that fixes this. I have already written a patch for Project Dependency that is waiting on the fix to Drupal core.

I have already added heuristics to better guess the correct project. No matter what I do there are going to be cases that break the automated testing. If I change the heuristics to make your situation work than how do I know I will not break more that are currently working? Continuing to add to the coding for the heuristics is just going to make the code impossible to maintain. Drupal core has to address their design flaw. The patches are available to do this.

So are you suggesting that I choose which project should be used? No matter which way I choose I will have someone mad because automated testing does not work. And it would require a lot of work for me and drupal.org webmasters deploying these exclusions. In a year we would have a list of exclusions and no one will remember why something was added to the exclusion list and if it is still needed.

> Yes, I am. There's obviously a winner here.

Yeah. It should be the older module. When there'll be a problem with that then we will deal with that but for now that heuristics is good enough.

Filed an issue in Quizz and the maintainer asks what to do: #2379493: This module breaks automated tests.

Similar issue in webform_patched: #2379485: This module breaks automated tests.

There will soon be a large number of projects ported to Drupal 8 and it will not be uncommon for other projects to encounter this same problem.

There is a variable for excluding dependencies. However, my recollection is this excludes dependencies but does not mean that any dependency will appear in their place. So I do not believe that variable will work for any of these cases of choosing a different project. So I expect this will require writing code. It is a long process for adding code to this project. I have to be able to reproduce the problem which means I have to request from the infrastructure team an update to my clone of drupal.org. Once I have that then I can try to write code for this exception. I have already added quite a few heuristics to try to fix things so the code is very complicated. Any changes will break other projects. If I add code to always pick quiz instead of quizz then quizz will be broken. In this case that may be acceptable. But it will not be the case for all the exceptions. Someone may say that I should just add a heuristic that always choose the older module. Well, the php module was forked from Drupal core and spun off into its own project. In that case we want the most recent fork. Once I have added the code and done enough testing to be reasonable sure I am not introducing a bigger problem then I need to get someone on the infrastructure team to update drupal.org. Then I should try to monitor the log messages on drupal.org to make sure any unanticipated problems do not occur. I would guess this would take about a week or more of my time plus additional time from the infrastructure team. The code currently is so complex that it is difficult to maintain and adding more exceptions will only make it impossible to maintain.

I updated the patch for Drupal core #2205271: Project namespace for dependencies and it passes. It took about two days of work to go through it line by line to get it working again.

I will request an update to my clone of drupal.org so I can reproduce the problem and investigate any possible fixes. I have already submitted a patch #2205271: Project namespace for dependencies that corrects this design flaw and the patch is passing tests. All it requires is a review of the patch, moving to RTBC and committing the patch. That is a lot less work than adding another exception to Project Dependency and it will fix the problem instead of just changing which projects have automated testing broken. Once Drupal 8 is fixed the patch for Drupal 7 will be pretty easy since it will have to completely backward compatible and thus will be a smaller patch.

I agree with trobey's assessment and proposed path forward.

There is nothing we can do on the Testbot to override dependencies ... they are passed to us by project dependency as part of the initial test request.

I had my development environment update for another issue so I ran some tests on this issue. I am very puzzled. First, when I click the link for the testbot above it seems to be returning the Quiz project and not the Quizz project. Second, Project Dependency does not return any information about the project being tested. There are two parts to Project Dependency. The first runs when a release is created. Testing this I get:

$ drush pdpv quiz 7.x-5.x-dev
Processing dependencies for quiz: 7.x-5.x-dev
Array
(
    [matching] => Array
        (
            [0] => quiz
            [1] => quiz_question
        )

    [truefalse] => Array
        (
            [0] => quiz
            [1] => quiz_question
        )

    [quiz_directions] => Array
        (
            [0] => quiz
            [1] => quiz_question
        )

    [scale] => Array
        (
            [0] => quiz
            [1] => quiz_question
        )

    [quiz_page] => Array
        (
            [0] => quiz
            [1] => quiz_question
        )

    [quiz_question] => Array
        (
            [0] => quiz
        )

    [multichoice] => Array
        (
            [0] => quiz
            [1] => quiz_question
        )

    [short_answer] => Array
        (
            [0] => quiz
            [1] => quiz_question
        )

    [long_answer] => Array
        (
            [0] => quiz
            [1] => quiz_question
        )

    [ajax_quiz] => Array
        (
            [0] => quiz
        )

    [quiz_stats] => Array
        (
            [0] => quiz
            [1] => charts
        )

    [quiz] => Array
        (
            [0] => ctools
            [1] => entity
            [2] => filter
            [3] => views
            [4] => views_bulk_operations
        )

)

When the dependencies are requested from Project Dependency it uses the information stored above to compute the complete list of dependencies:

$ drush pdsd quiz 7.x-5.x-dev
Array
(
    [2220025] => Array
        (
            [uri] => charts
            [version] => 7.x-2.0-rc1
            [tag] => 7.x-2.0-rc1
            [dependency_type] => 0
        )

    [2378333] => Array
        (
            [uri] => ctools
            [version] => 7.x-1.5
            [tag] => 7.x-1.5
            [dependency_type] => 0
        )

    [2236077] => Array
        (
            [uri] => entity
            [version] => 7.x-1.5
            [tag] => 7.x-1.5
            [dependency_type] => 0
        )

    [2271305] => Array
        (
            [uri] => views
            [version] => 7.x-3.8
            [tag] => 7.x-3.8
            [dependency_type] => 0
        )

    [2161705] => Array
        (
            [uri] => views_bulk_operations
            [version] => 7.x-3.2
            [tag] => 7.x-3.2
            [dependency_type] => 0
        )

    [2379339] => Array
        (
            [uri] => xautoload
            [version] => 7.x-5.1
            [tag] => 7.x-5.1
            [dependency_type] => 0
        )

)

As you can see Project Dependency does not return a dependency on the Quizz project or even the Quiz project. So unless I misunderstand the issue I do not see how Project Dependency has anything to do with this issue.