Should .emulators be moved to a separate package?

[rhugman]

G'day folks -

The Emulator package has been growing. It is now starting to incur nasty things such as tensorflow dependencies. I have plans to add more nasty autoencoder architectures as well.

Q: does it make sense to move Emulators to its own package? (i.e. pyemusquared "py_emu _emu_lators", get it? haha) Or is sticking to the current optional dependency approach good enough?

I suppose the core issue is the pytest suite. Emulator tests are incurring much of the runtime, and this is growing for OS & python versions that are supported by tf. Which is a whole other complication in itself...tf python/OS support is limited.

Thoughts? Opinions?

[jtwhite79]

I'm fine either way...the trend these days does seem to be away from big monolithic packages that do everything so in that respect it makes sense. As long as we can maintain a seamless pipeline between the emulators and pyemu, I'm good...

[briochh]

I think separate could work. But yes, we def want to be well coordinated between pyemu, pyemu**2, pypestutils, pypestvis, and even pestpp. Maybe some sort of dedicated testbed repo that deals with testing all the cross links?