Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python 3 - resources_task creating unexpected targets after reset #6384

Closed
Eric-Arellano opened this issue Aug 22, 2018 · 2 comments
Closed
Assignees
Labels

Comments

@Eric-Arellano
Copy link
Contributor

Problem

Both of the test_incremental() tests are failing in test_resources_task.py.

==================== FAILURES ====================
                     _ MinimalImplResourcesTaskTest.test_incremental __

                     self = <pants_test.backend.jvm.tasks.test_resources_task.MinimalImplResourcesTaskTest testMethod=test_incremental>

                         def test_incremental(self):
                           task = self.create_resources_task(target_roots=[self.create_target('a:1'),
                                                                           self.create_target('b:1')])
                           processed_targets = task.execute()

                           self.assertEqual(sorted([self.target('a:1'), self.target('b:1')]), sorted(processed_targets))
                           self.assert_products(task, self.target('a:1'), 1)
                           self.assert_products(task, self.target('b:1'), 1)

                           # Test incremental works - no changes.
                           self.reset_build_graph()
                           task = self.create_resources_task(target_roots=[self.create_target('a:1'),
                                                                           self.create_target('b:1')])
                           processed_targets = task.execute()

                     >     self.assertEqual([], processed_targets)
                     E     AssertionError: Lists differ: [] != [TestTarget(a:1), TestTarget(b:1)]
                     E
                     E     Second list contains 2 additional elements.
                     E     First extra element 0:
                     E     TestTarget(a:1)
                     E
                     E     - []
                     E     + [TestTarget(a:1), TestTarget(b:1)]

                     .pants.d/pyprep/sources/0149f6d60c1f81255ffbf3cd4ca6bef56274a538/pants_test/backend/jvm/tasks/test_resources_task.py:136: AssertionError

To reproduce

  1. ./pants clean-all
  2. ./pants --python-setup-interpreter-constraints='["CPython>=3.5"]' test tests/python/pants_test/backend/jvm/tasks:test_resources_task.py

My confusion

I don't understand why process_targets is supposed to be empty in the last line, after calling task.execute().

  def test_incremental(self):
    task = self.create_resources_task(target_roots=[self.create_target('a:1'),
                                                    self.create_target('b:1')])
    processed_targets = task.execute()

    self.assertEqual(sorted([self.target('a:1'), self.target('b:1')]), sorted(processed_targets))
    self.assert_products(task, self.target('a:1'), 1)
    self.assert_products(task, self.target('b:1'), 1)

    # Test incremental works - no changes.
    self.reset_build_graph()
    task = self.create_resources_task(target_roots=[self.create_target('a:1'),
                                                    self.create_target('b:1')])
    processed_targets = task.execute()

    self.assertEqual([], processed_targets)
@jsirois
Copy link
Contributor

jsirois commented Aug 22, 2018

This is a b'' != '' under python3 bug in the CacheManager code graph. Fix forthcoming.

@jsirois
Copy link
Contributor

jsirois commented Aug 22, 2018

Fix lumped into #6379 with 053fb46.

jsirois added a commit that referenced this issue Aug 22, 2018
Without this, the template was rendered with literal `\n`'s under
python3. I did not linger to figure out how the rendered string could
possibly load in a python interpreter with no errors!

Also fix the `BuildInvalidator`.

Previously it wrote and read keys asymmetrically; now the key is
uniformly represented (and compared!) as a unicode utf-8 string in
memory.

Fixes #6354
Fixes #6384
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants