Is there really an added value to couple the pycox to torchtuples?

While torchtuples simplifies the interfaces of code usage quite a lot, it appears that the interface of functions highly depends on the implementation, as well as the semantics of torchtuples, while in many cases, especially for research purposes, it might be in favor to expose the detailed model implementation and the training/testing procedure, and the encapsulation of both inside torchtuples may significantly reduce the overall readability and flexibility, e.g. quite huge amount of time may be required to write code for bridging.

But if I understand the codes correctly, it is also true that the `base.Model` can take pre-trained `nn.Modules` and perform predictions directly, which means any external models can be brought into the pipeline of pycox, which is quite neat. It might be possible to decouple the pycox from torchtuples to some extent, i.e. under the assumption that the model is always nn.Module, and the input/target as tensors, while another wrapper can be put into effect to bridge pycox and torchtuples, which means the flexibility retain to use pipeline with or without torchtuples.

Still, really appreciate the effort. I gotta say it is amazing that eventually there is an awesome pytorch version of DeepSurv here:)

Start by reading the current base.Model interface and how it depends on torchtuples, then trace the handling of pre-trained nn.Modules and tensor inputs. Compare the existing pipeline with the proposed independent nn.Module path. Done requires an agreed decoupling design and clear compatibility boundaries; this issue does not name specific files or tests.

Written by the indexing model from the issue text.