Any plan to make the repo usable for tf.keras ?

[ksachdeva]

Hi,

Modules in keras-applications repo uses a strategy such that one has a choice to use either keras or tf.keras i.e. there are no imports of either of them (keras / tf.keras) in the code thereby not requiring an explicit dependency

Is there any plan to use the same strategy for this repository as well ?

Regards & thanks
Kapil

[gabrieldemarmiesse]

There is the strategy of avoiding to use direct imports by passing the modules to the functions called. It's not super pretty. I believe that making a fork which has different imports would be much easier to maintain. We would just need to merge once in a while and to change the imports. Maybe also changing the travis file will be needed. In any case, this is fairly easy to do. If you are willing to do it, I would be more than happy to guide you.

[ksachdeva]

Thanks @gabrieldemarmiesse for a quick response

I believe that making a fork which has different imports would be much easier to maintain. We would just need to merge once in a while and to change the imports.

I am not sure if I understood this part. If we use the same strategy of dynamic module import as in keras-applications and use some meta-programming techniques (factory to make classes etc since custom layers would need to inherit from Layer) there would be no need to maintain a fork etc.

Most likely am missing something here and hence trivializing the problem. Would appreciate if you can guide.

Regards
Kapil

[gabrieldemarmiesse]

The idea is that we have to choices, each with pros and cons:

1. The method used in keras_applications.

• Pros: One single codebase.
• Cons: Hacky. Error prone, not easy to add new features, imports needs to be done in the function/class, imports are not flexible. We need to duplicate declarations.

2. Making a fork.

• Pros: Everything happens in the upstream repo and it's easy to add features (no hacky argument forwarding). Easy to debug. If no imports are added or changed in upstream, merging upstream into master is one line in bash, and we have nothing else to do.
• We have two codebases.

The first method is a pure python solution. The second method is a pure git solution. Both have pros and cons. I prefer option 2 as I believe it will be very little/ no work at all to maintain. (git magic).

[gabrieldemarmiesse]

Just to be clear: for me, maintaining a fork means "merging upstream once every two weeks and changing the imports if any were introduced recently". This means nearly zero work if no imports were changed since the last merge.

[ksachdeva]

Thanks for clarifying.

I agree that debugging will be bit harder ... also if some one wants to contribute they would have the burden of going via the factory/meta-classes etc.

That said, if all of the hacky/meta stuff can be isolated in a way that the burden on new contributions is minimized (i.e. there are conventions in place) it may be okay after all. I am not an expert on python meta programming however I have a reason to believe that "imports needs to be done in the function/class" can be avoided.

I do see and appreciate your dilemma though !

I am going to do an exercise in writing a custom callback and see how elegant (or not) it is to have a notion of dynamic base class. Will share the result/code with you and may be that will help make a choice.

[gabrieldemarmiesse]

While trying to implement it by just converting the imports with a script, I've hit a roadblock. There seems to be an issue with tensorflow itself having a keras API slightly different concerning the handling of the shapes. This API also seem to have a bug in it, in the function add_weight. Which makes custom layers with weights unusable. It seems tf.keras requires TensorShapes, but those are not present in keras. So the APIs are not completely compatible. I tried to hack through, but couldn't because of the bug. I think I'll work on it more when TF 2.0 is out. I'll continue the PR then.

[gabrieldemarmiesse]

I worked more on it, see #387, it is actually possible to support keras and tf.keras right now. I'll merge this PR this week end and add some instruction on how to install the tf.keras version of keras_contrib.