Should this be a repo?

[benjaoming]

My concern is the following:

In KA Lite, there was a package called fle_utils. It was located in an external package to kalite (although still in the same repo). It became a sort of dumping ground in which hierarchies and structures weren't considered, alas a giant tech debt.

I'm not saying that this is a mess, in fact there's too little code for that :) ..but it's the direction.

I can see that there has been a consideration of how to avoid duplicating "CONSTANTS" in multiple repos. I put "CONSTANTS" in a quotation marks on purpose......

The thing is with versioning. Things change. So they get versioned. Even constants change.

I can ask the question: Which version of le_utils are you using, and what does those constants origin from?

They would supposedly by from a protocol of some sort. But perhaps the protocol itself is defined mainly in the scope of the kolibri app.

So instead of creating this repo and package for distribution and versioning, I would suggest the following:

Move the constants into kolibri.utils and have that be the versioning scheme for now.

In the longer run, though, it all should go in to a protocol, which is more of a specification. The protocol might still live in kolibri, but if it's stack is too huge to have installed on the host systems of ricecooker and content-curation, then it should be factored out.

[rtibbles]

The other issue here, is that the constants defined in here are defined in Python.

However, the content kinds, and the exercise mastery models defined herein are needed on both the client and server side in mainline Kolibri (and I assume are also required similarly in the content curation server).

@jamalex had suggested that we could bootstrap constants into the frontend using the plugin infrastructure, but it might be better to make these things available at build time, by using a language agnostic format.

[aronasorman]

kolibri.utils

This is the main problem. We encountered this before in the central server, where we did not factor out the commonalities between the central server and the distributed kalite app. They got too mixed up, and now their interfaces are very ill-defined.

I think this being a separate python repo is a good compromise. We both constrain what is available -- restricted to just constants -- while leaving the option to go another direction. The thing I don't want is to have the ricecooker and cc server depend on a full-blown Kolibri.

I agree with @rtibbles that if there's a way to have them shared across different languages, then let's go with that. Maybe we can, as part of the build process, extract the constants from python code to JSON? That seems to much magic. Might be better to stick with a language-agnostic format in the first place.