[CHORE] Refactor Repo Structure to Allow Multiple Languages

[nkpng2k]

@osery with cpp mojo's there will me more deployment strategies that implement python/alternative language to java.

Opening this issue to track thoughts here:

1. perhaps we can do something similar to what we have in DAI with a Makefile, and nest the projects into their own separate directories. e.g.

   dai-deployment-templates
   |-- Makefile
   |-- python
       |-- cpp mojo project
       |-- azureml project
   |-- java
       |-- original java mojo projects.

   then we can change the java build process to dump the builds into a build directory... same as whatever we chose for the python side and then compile both build directories and zip them to ship.

WDYT?

[nkpng2k]

cc @mmalohlava @achraf-mer

[osery]

Hi Nick, thanks for starting this.

Are there some alternatives? Personally, I find Make a very bad way to build projects. It does not really track dependencies so it is almost impossible to do correct incremental builds :(. The way DAI is build is imho super painful and you never know if the right thing gets actually built or not.

Gradle itself seems to have some support for Python and C++ builds:

• Python: https://github.com/linkedin/pygradle
• C++: https://docs.gradle.org/current/userguide/building_cpp_projects.html I admit that I have never used these myself.

We use Bazel in Model Manager and build Golang, Typescript, and Python with it to our great happiness (it also supports Java and C++). Bazel has a rather steep learning curve, but once set up, it is really great way to build things quickly (remote caching) and consistently (tracks all dependencies).

I understand both these options are much more work, but I am really scared we could end up with thousands lines of make code that is super hard to maintain or even do correctly to start with. Wdyt? @mmalohlava

[achraf-mer]

@nkpng2k my 2cents: If we end up using make, I would suggest to split things based on clouds rather than py/java. In my opinion, if things like Azure requires an azure-cli, it's easier to limit the implementation scope in one place, we can then have subdirectories with an ugly make interface (clean, build, deploy) for aws/azure/etc.. and just use a python wrapper or a master make to control what needs to go where.

[nkpng2k]

@osery thank you for pointing out bazel and pygradle. I would be inclined, actually, to lean towards one of those. Agree, the Makefile in DAI is super unwieldy.... Wouldn't mind being forced to learn bazel.

[nkpng2k]

@achraf-mer I actually think, given the fact that this repo is for production ready code, we really should never be implementing things that require a cli. In general, we should expect that at least half of these implementations will be deployed either by dai (python) or by some other product built by us (puddle, model management, etc) adding a cli as a dependency to these projects is basically a no-no from my perspective.

[achraf-mer]

@nkpng2k not pushing to use a cli, just stating if something requires a cli, then the scope need to be limited, this goes for other cloud specific tools as well.

[nkpng2k]

@achraf-mer can we maybe revisit this? I think given that now we have the c++ dai mojo, it is really time to start trying to make this repo multiple language supported. WDYT?

[achraf-mer]

@achraf-mer can we maybe revisit this? I think given that now we have the c++ dai mojo, it is really time to start trying to make this repo multiple language supported. WDYT?

Agree, if not necessary to have a common packaging tool we can work with Makefiles

[nkpng2k]

Yes I think the only thing we need to be concerned with is unified packaging for the java stuffs that is used to dai. The other stuff is entirely separated