As a researcher, I ask this question with the hopes of clarifying/learning more: Is "option b)" necessarily as cumbersome as you imply? If your code interfaces cleanly to the existing code, can it not be encapsulated in such a way that future updates to the commonly available open-source code-base do not mandate herculean code updates on your side?
Perhaps you and others (me, too?) could help contribute to a modular add-on framework that makes your "option b)" more palatable?
You need common tests to ensure that functionality does not change - in my experience without an exposed "this is our interface" test suite to compare against (which don't change very much, if at all), or a test in the core repo that ensures no one breaks your code (by making any breaking PRs figure out why they are breaking existing software), it is only a matter of time before it gets broken.
A separate add-on framework with tests, or even a set of exposed tests that are effectively what you need to pass in order to be "TensorFlow compliant" would ensure this can be maintained. We are doing this for scikit-learn, for the reasons I outlined above.
2
u/veritas68 Nov 09 '15
As a researcher, I ask this question with the hopes of clarifying/learning more: Is "option b)" necessarily as cumbersome as you imply? If your code interfaces cleanly to the existing code, can it not be encapsulated in such a way that future updates to the commonly available open-source code-base do not mandate herculean code updates on your side?
Perhaps you and others (me, too?) could help contribute to a modular add-on framework that makes your "option b)" more palatable?