Make API available in v2.0

[yulqen]

Certain elements of the API exposed to users are used heavily by the DfT. These need to remain available in v2.0, possibly with deprecation warnings if currently imported from the incorrect module.

[yulqen]

The primary function being imported for writing analysis scripts, etc, is utils.project_data_from_master. This is actually the wrong approach - this function is not intended to be exposed to the user and could undergo internal changes in future development. The formal API includes a safe, encapuslated version of this function at api.project_data_from_master_api. see bcompiler docs. (My fault, for not enforcing it ages ago!)

The approach for bcompiler 2.0 (and subsequently datamaps) is to "enforce" the api version and assign deprecation warnings to the user from the utils function, advising them to amend their import statements.

Migration tasks

• check understanding above is correct
• create test suites
• check whether any other API functions or internal functons are being relied upon in user scripts
• migrate all api code objects (Master, Quarter objects, etc) into a new api package in bcompiler 2.0.
• create a new project_data_from_master function in bcompiler-engine to accomodate this use, with improved safety notifications if required.

[yulqen]

The current api package offers objects such as Master and Quarter, and the project_data_from_master API function disussed here uses these intriniscally.

Are these objects a good idea in bcompiler? They represent business entities from a particular real world context - portfolio management, and in particularly portfolio management at DfT which is fine, but there is a case for thinking that these could be put in a plug-in; or perhaps that bcompiler itself (or datamaps - is a portfolio-specific front-end to bcompiler-engine.

It's clear that these are required to go into bcompiler, but I'll have to think about whether they should be further broken out into a plugin-like structure.