Lock ivy resolution based on the cache directory being used.

Review Request #3529 — Created March 2, 2016 and submitted

patricklaw
pants
3000
pants-reviews
benjyw, jsirois, nhoward_tw, stuhood, zundel

This strategy uses a cross-process file lock. Since
there are no reentrant uses of ivy execution (nor should
there be), there is no potential for deadlock.

This is less performant than using a separate directory
for resolution reporting than the directory used for
artifact downloading, but no worse if the user is
already configured to use a non-global cache.

Travis: https://travis-ci.org/pantsbuild/pants/builds/113293163

All existing ivy tests pass, which exercise both resolution
code paths that this code affects. Jenkins passed on fresh
machines with no ivy errors (a first) with this patched in.

  • 0
  • 0
  • 1
  • 0
  • 1
Description From Last Updated
ZU
  1. Ship It!
  2. 
      
NH
  1. Ship It!
  2. 
      
BE
  1. 
      
  2. src/python/pants/ivy/ivy.py (Diff revision 1)
     
     

    It's weird to me that this is a property. It doesn't return anything, and it's intended to be used a contextmanager, so I think property syntax is more obscuring than enlightening.

    1. I'm trying to simulate the standard python lock mechanism, wherein you get a lock object, then just use a context manager over the object itself: https://docs.python.org/2/library/threading.html#using-locks-conditions-and-semaphores-in-the-with-statement

    2. Fair enough.

  3. 
      
BE
  1. Ship It!
  2. 
      
PA
PA
Review request changed

Status: Closed (submitted)

Change Summary:

Commit 3d2cf5d8a1d4aa70ad595675aefd7a63899c8510

Loading...