RFC: Best practices for custom operations in TensorFlow #126
Conversation
alextp
requested review from
ewilderj,
goldiegadde and
martinwicke
as code owners
ewilderj
changed the title
|
@alextp, That's fantastic! Is there a plan to add XLA op as an example as well? |
| their op names are globally unique across the entire TF ecosystem. To do so, | ||
| prepend the package’s name to the op’s name and separate with a ‘>’. An op named | ||
| “MatMul” inside the “tensorflow_addons” package should be named “Addons>MatMul”, | ||
| for example. |
There was a problem hiding this comment.
@tensorflow/sig-addons-maintainers Seems that we need to rename all C++ ops? cc @seanpmorgan
|
|
||
| Since an op’s name uniquely identifies it, different TF packages should ensure | ||
| their op names are globally unique across the entire TF ecosystem. To do so, | ||
| prepend the package’s name to the op’s name and separate with a ‘>’. An op named |
There was a problem hiding this comment.
Can we make tf.load_op_library throw a warning or even an error if there is no package name specified? AFAIK only custom-op repos utilize this function
|
So I took a stab at implementing this for Addons... but currently it'll throw an "Invalid Op Name" because of the What will the behavior be once the package separating character is accepted? At the moment the camel case op name is lower-cased and separated by
|
| stories and backwards compatibility. | ||
|
|
||
| Around (but technically not a part of) TF 2.0, however, TensorFlow supports [a | ||
| straightforward way for third-party package to build and deploy their own custom |
|
|
||
| | Status | Proposed | | ||
| :-------------- |:---------------------------------------------------- | | ||
| | **Author(s)** | Alexandre Passos (apassos@google.com | |
| - each downstream package can choose its own backward and forward compatibility | ||
| processes, allowing fine-grained trade-offs between velocity and stability | ||
|
|
||
| ## Out-of-tree ops must be namespaced |
There was a problem hiding this comment.
The namespace problem is similar to the naming discussion in the Standardizing Composite Operations In TensorFlow RFC.
Any thought around making the naming scheme more unified?
change Status to Accepted
|
Ready to merge the RFC but I never heard back after the design meeting. Are there any notes to share? Was this design accepted? |
|
Yes, this can be merged. Comments have already been integrated as far as I can tell. |
ewilderj
added
RFC: Accepted
Review period is open through 2019-08-09
Best practices for custom operations in TensorFlow
For most of TF’s history, it was very expensive for third-party packages or libraries to release their own tf operations. This created pressure to put ops in tf core or in tf contrib, which created some uncertainty around support stories and backwards compatibility.
Around (but technically not a part of) TF 2.0, however, TensorFlow supports a straightforward way for third-party packages to build and deploy their own custom TF ops. To maintain a healthy ecosystem, we recommend best practices in this RFC.