Currently, users of the psm_reqs Python module are expected to first convert the requirements to CSV format (using xlsx2csv) and then initialize by calling psm_reqs.get_reqs(csv_file). This is a case of implementation poking through the API in an inappropriate way. Instead, psm_reqs should handle it all internally: the user should just call psm_reqs.get_reqs("/path/to/RTM.xlsx") and the module would (transparently, in the background) use the Python subprocess module to invoke xlsx2csv itself and parse the requirements from the resultant CSV stream.
One kluge resulting from the current situation is that refresh-dashboard pretend-parses psm-dashboard-config.json to get the value of the "psm_reqs" parameter, just to build a CSV and hand it off to psm_reqs.
Currently, users of the
psm_reqs
Python module are expected to first convert the requirements to CSV format (usingxlsx2csv
) and then initialize by callingpsm_reqs.get_reqs(csv_file)
. This is a case of implementation poking through the API in an inappropriate way. Instead,psm_reqs
should handle it all internally: the user should just callpsm_reqs.get_reqs("/path/to/RTM.xlsx")
and the module would (transparently, in the background) use the Pythonsubprocess
module to invokexlsx2csv
itself and parse the requirements from the resultant CSV stream.One kluge resulting from the current situation is that
refresh-dashboard
pretend-parsespsm-dashboard-config.json
to get the value of the "psm_reqs" parameter, just to build a CSV and hand it off topsm_reqs
.