Add public API markers to targets and base tasks used by 4qs plugins.

Review Request #3746 — Created April 22, 2016 and submitted

mateor
pants
3253
pants-reviews
jsirois, molsen, patricklaw, stuhood, zundel
The targets are sefl explanatory - we consume products of these
targets in plugin tasks. The fingerprint strategy is a core tool
in a task developer's toolbox.

If the task involves jvm code, then it may need do jar operations,
this exposes as public some of those tasks.

Ivy is marked public because it provides a custom exception that
doesn't inherit from anything descriptive - Ivy.Error is just an
Exception. We publish jars with a custom pom-publish task - where
every jar has a common version. Catching Ivy failures required
catching Ivy.Error.

I ran the unit tests locally to catch style or syntax errors.
Running the CI to be sure since we are getting so close to release.

https://travis-ci.org/pantsbuild/pants/builds/125091874

ST
  1. 
      
  2. Are you subclassing all of these different targets, or just referencing them?

    We would probably want to discourage subclassing in favor of macros/composition instead...

    1. Almost all of the targets are being used in one of two ways:
      - downstream tasks that consume their products
      - Uninstall the pants task that usually operates over a target and instead use a custom task.
      -
      PythonBinary is one of the latter - we use vex and have no pex. But we don't want to opt-out of the entire task pipeline for that product, only replace one of the tasks in the chain.

  3. src/python/pants/base/fingerprint_strategy.py (Diff revision 1)
     
     
     
     

    May I recommend extending TaskIdentityFingerprintStrategy instead? This will not include the options fingerprint for your task.

    1. This is the helper for target fingerprints, targets don't have options. An option here might be the DefaultFingerprintStrategy subclass, but that is indicated as unsafe when the target mixes in instance attributes.

      Task (and by extension Target) developers should be welcome to the fingerprint API, imo.

    2. oh wait. I see, maybe that would work. Let me see what I would need to do for that.

    3. Okay, I think that the answer to this is probably yes, we could switch - the implementing tasks both predate the TaskIdentityFingerprint. I will give it a run.

  4. 
      
MA
MA
ST
  1. 
      
  2. src/python/pants/backend/jvm/tasks/jar_task.py (Diff revision 3)
     
     
     
     
     
     

    Would be great to not make this public, and to have a product interface between the task creating the jar and the task requesting it, but I guess this is reality right now.

  3. 
      
MO
  1. Ship It!
  2. 
      
MA
Review request changed

Status: Closed (submitted)

Change Summary:

Thanks Stu, Matt. Submitted.

Loading...