Pyroma reports "I couldnt' find any package data"

[aclark4life]

I'm not sure when this started, or why it's happening but pyroma seems to be reporting it can't find any packages to evaluate e.g.

aclark@Alexs-MacBook-Air:~/Developer/Pillow/ > pyroma .
------------------------------
Checking .
Found nothing
------------------------------
I couldn't find any package data
------------------------------
Final rating: 0/10
This cheese seems to contain no dairy products
------------------------------

Normally it outputs:

# > pyroma .
# ------------------------------
# Checking .
# Found Pillow
# ------------------------------
# Final rating: 10/10
# Your cheese is so fresh most people think it's a cream: Mascarpone
# ------------------------------

[aclark4life]

@regebro any thoughts?

[hugovk]

git bisect is just the ticket for finding when this started.

We should add a test case too.

[hugovk]

Following this git bisect guide,

git bisect start
git bisect good 2b32882a # Pyroma rating was added to setup.py
git bisect bad b6d3983 # A recent commit

And then repeatedly running pyroma . followed by git bisect good for a 10/10 and git bisect bad for a 0/10, results in:

2be4e9f3e5f433aa34e73ed225837ca0ebd06a5c is the first bad commit
commit 2be4e9f3e5f433aa34e73ed225837ca0ebd06a5c
Author: wiredfool <eric-github@soroos.net>
Date:   Tue Jun 24 15:57:24 2014 -0700

    Multithreaded build

:000000 100644 0000000000000000000000000000000000000000 0ff5b4b62be99b417bea17766a03c648877fc5a0 A  mp_compile.py
:100644 100644 2fbcc29596359084e793b1486c351fb98654ef65 1a31a898180eeaab8f732c94c3b2ba285bfb3d1f M  setup.py

Commit 2be4e9f shows setup() was moved inside the if __name__=='__main__': section.

Going back to HEAD, moving setup() out of __main__ gives a 10/10, and leaving it in gives 0/10.

[hugovk]

This test case fails with setup() inside __main__ and passes with it outside.

from helper import *

# TODO skip if not installed
from pyroma import projectdata
from pyroma.ratings import rate


class TestPyroma(unittest.TestCase):

    def test_pyroma(self):
        # Arrange
        data = projectdata.get_data(".")

        # Act
        rating = rate(data)

        # Assert
        # Should have a perfect score
        self.assertEqual(rating, (10, []))


if __name__ == '__main__':
    unittest.main()

# End of file

[regebro]

Pyroma switches out setup() for it's own method that just collects the data passed in, but doesn't perform any actions, and then imports setup.py. By moving the setup() call inside __main__ it never gets called.

If I was to execute setup.py instead it would solve the problem in this case, but it would also execute your unit-tests, which we don't want. Also I think other modules do much worse things than run tests inside __main__ so it's generally not a desirable option.

All this of course just highlights one of the problems with the distutils architecture. But we are stuck with it for the forseeable future.

[aclark4life]

Yeah, I'm not a fan of moving setup inside __main__ can we revert that @wiredfool ? Or somehow accomplish your goals without doing that? And thanks @hugovk and @regebro (wow great lesson on git bissect!)

[aclark4life]

On the other hand, if this is the only casualty and mp_compile.py is worthwhile then I guess we could leave things as is.

[wiredfool]

I think we can revert that. The module that we're running with multiprocessing has to be importable, but that is mp_compile. My quick tests here are showing that taking out the __main__ condition on the block doesn't affect the multithread compiling.