-
Notifications
You must be signed in to change notification settings - Fork 651
Migration of keras-team/keras-contrib to tensorflow/addon #519
Comments
hi, I would like to be able to do this: "from keras_contrib.layers import CRF", as before. |
The CRF is available in tf.addons. See tensorflow/addons#314 |
Hi, @gabrieldemarmiesse, why doesn't it have a CRF layer implementation in tf.addons.text. The original one has this, as you can see: https://github.com/keras-team/keras-contrib/blob/master/keras_contrib/layers/crf.py |
Hi @lingvisa we currently have CRF layer under review: Separately, TF Addons is happy to review any keras-contrib functionality that has proved useful and well tested as it should most likely align with our API formats. Looking forward to merging a lot of the great functionality of this repo with the ability to write custom TF ops/kernels in our library. |
@gabrieldemarmiesse That would be great, if the layer can be added. Thanks. |
@lingvisa We would need to find a maintainer for the CRF layer in tf addons to add the layer. I'm too busy with keras to do that at the moment. Hopefully, someone else will volunteer to do it. |
@gabrieldemarmiesse Is there a list of features in keras-contrib that should be moved to tensorflow/addons? Can dedicate some time to migrate stuff over the next few weeks |
I think the problem is that none of knows exactly which functions/classes are in keras-contrib and which functions/classes are in tensorflow-addons. I didn't have the time to look into it. If we had two lists we could compare easily and then know what to migrate. That's not super fun to do sadly :( |
Generated components using the TensorFlow Addons:
Keras-Contrib
|
Thanks a bunch @seanpmorgan, I'll go over each of the items and then make a list with a proposition of what is relevant. Also since there are a lot of classes in keras-contrib that are not relevant anymore (e.g. TensorboardGrouped). |
Can be migrated and have maintainers
Can be migrated but no maintainers
@seanpmorgan do you want to make a selection? What do we do about features without maintainers? |
@gabrieldemarmiesse imo, CyclicLR shouldn't be migrated as a callback, but rather as a LearningRateScheduler. Could also be split into different schedulers to avoid the |
Yup, I agree with the splitting. Seem good. |
Probably would be best that we create an issue for each maintained piece so the community can comment. In general though those all look pretty useful so if the maintainers are willing to maintain on TF Addons then I see no reason we can't move them. For the ones without maintainers maybe we can open an issue to see if there is anyone interested in maintaining provided there is a community need for them |
Doesn't it make sense to freeze the main Keras repo and evaluate Keras issue migration and decoupling with TF.keras ticket on TF repore before migrating contrib to add-on? |
@bhack I agree that Keras repo needs to decouple where tickets are going... but I'm not sure that's preventing existing functionality in contrib to be migrated? Could you further explain that point? |
Here you have in the list on addon side |
We are still having tripled bugs with a risk to have fourfold cases: |
Hi, I am not able to import the tf version for keras_contrib :
I can see the module in my Have restarted my jupyter-notebook server and still is not able to pick up the module. Any help would be great. |
@rajveershringi did you solve this problem? |
@soumayan unfortunately not. |
@rajveershringi did you follow this link? |
Hi, I will migrate the SineRelu activation function this week. Cheers, |
I think tf/addons is probably my preference, to reduce the overhead of management. A lot of component in tf/addons is already based on keras classes like layers. @fchollet, what's your thought? |
We need to careful think about this as we also have a new threshold in Addons about accepting new contributions (>50 citatons). So It Is not anymore "what It Is too experimental will go in addons": As we highly depend on keras we could have overlaps/duplicates with components that your maintain in the new keras standalone repo or keras-cv/keras-nlp (also if currently they are just a model garden sub-mirror). About the custom ops I hope that we could reduce the numbers of custom ops we are maintaing cause they have a quite large maintainership overhead and a restricted HW compatibility. /cc @seanpmorgan @yarri-oss @thealamkin |
hi, any plans to migrate ftml? |
Hello all,
Keras-contrib host many good features. We'd like to keep them. Since we're focusing on tensorflow, and will deprecate the multi-backend Keras, we need to think about what will happen to other keras-related projets.
The goal of keras-contrib and tensorflow/addons are very similar, but tensorflow/addons benefits from a better support (read workforce) from google. With many processes already in place to make the maintenance easier.
As such, we'll deprecate keras-contrib. People who would like to keep a feature and are ready to maintain it should do a pull request to tensorflow/addons.
We don't have a timeline yet as of when we get this repository out of github.com/keras-team but it will happen eventually.
If you have any questions concerning the migration or if you need help with it, feel free to comment below.
The text was updated successfully, but these errors were encountered: