Export module

[MelvinMartins-NIST]

V1 of the MIDAS Export service.

This service provides endpoints to export project records or JSON payloads
into supported formats (Markdown, PDF, etc.).

Usage (example):

• POST /midas/export/v1
• Body: {
  "output_format": "pdf",
  "inputs": [ProjectRecord_object1, ProjectRecord_object2, ProjectRecord_object3, etc.],
  "template_dir": "/midas/export/templates",
  "template_name": "dmp_pdf_template.prep",
  "output_dir": "/midas/export/out"
  }

[RayPlante]

I'm seeing a failure generating markdown output, and it appears to be due to this line. This seems to set the path to something like templates/md/dmp_markdown_template.prep; however, the file I see in the under nistoar/midas/export has a path of templates/markdown/dmp_md_template.prep.

[Iskander54]

This branch is not done yet, since I'm also working on the portal, I'm going back and forth with the two branches.
This is an issue I have identified and I'll fix it.
I will let you know when this PR would be complete

[RayPlante]

Here are a few things I forgot to cover in our Teams conversation...

• (@MelvinMartins-NIST ?) When looking into above-mentioned bug, I noticed that to get the proper template path, the code must determine both a subdirectory name and filename within that directory, both of which depend on the format name. This fact has worked its way into some of the Python API signatures (e.g _determine_template_path()). Is there an advantage separating the templates into different subdirectories? Or would it be easier to put all of the files into a single directory? I'm thinking that this might make things easier if we provide an alternative directory.
• (@MelvinMartins-NIST) The nistoar.midas.export.run() function includes both an output_directory argument and a generate_file argument. If generate_file is True, then output_directory is required. Perhaps generate_file is unneeded, yes? Maybe have the implementation (clarified by documentation) that is output_directory is not given (e.g. empty or None), then the content is included in the returned object, all in the spirit of minimizing the ways the user can provide bad input.
• (@MelvinMartins-NIST ) At your convenience, go ahead and expand the in-line documentation by providing descriptions for the function arguments. If you would, go ahead and convert the argument list to the :param type name: format used by our Sphynx setup.
• (@Iskander54 ) Unless there is a known incompatibility with the latest version of a dependency (like, say, preppy), I have been specifying the dependency (in requirements.txt, docker/pyenv/Dockerfile, etc.) without specifying a version--i.e. always pull the latest version. This is based on the idea that it is better to suddenly discover a non-backward compatible change via a broken build than to not notice an update addressing a security issue. Please remove the version specifier where you are just referring to the currently latest version.
• (@Iskander54 ) At your convenience, merge the integration branch into export-module to address the conflicts and pull in latest fixes. (It was necessary for me to do this to get this working under the latest oar-docker.)