Pyroma reports "I couldnt' find any package data" #740

Activity

1. aclark4life

   added

   Bug

   on Jun 27, 2014
2. aclark4life

   added this to the 2.5.0 milestone on Jun 27, 2014
3. aclark4life commented on Jun 27, 2014

   

   aclark4life

   on Jun 27, 2014

   MemberAuthor

   More actions

   @regebro any thoughts?
4. hugovk commented on Jun 28, 2014

   

   hugovk

   on Jun 28, 2014

   Member

   More actions

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

   We should add a test case too.
5. hugovk commented on Jun 28, 2014

   

   hugovk

   on Jun 28, 2014

   Member

   More actions

   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 <[email protected]>
   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.
6. hugovk commented on Jun 28, 2014

   

   hugovk

   on Jun 28, 2014

   Member

   More actions

   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
   
7. regebro commented on Jun 28, 2014

   

   regebro

   on Jun 28, 2014

   More actions

   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.
8. aclark4life commented on Jun 28, 2014

   

   aclark4life

   on Jun 28, 2014

   MemberAuthor

   More actions

   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!)
9. aclark4life commented on Jun 28, 2014

   

   aclark4life

   on Jun 28, 2014

   MemberAuthor

   More actions

   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.
10. wiredfool commented on Jun 28, 2014

    

    wiredfool

    on Jun 28, 2014

    Member

    More actions

    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.
11. hugovk

    closed this as completedin #742on Jun 28, 2014