Resolve #106 per additional API changes

[nutjob4life]

📜 Summary

Merge this to resolve #106 but also work around additional changes to the server's delivery of data to the client.

See, previously, using pds.api_client (versions 0.4.0 and 0.5.0), you'd get the properties attribute of the pds.api_client.models.Product class with key-value pairs like this:

{
…
    'ops:Label_File_Info.ops:file_ref': ['https://pds-gamma.jpl.nasa.gov/data/pds4/test-data/registry/urn-nasa-pds-insight_documents/bundle_insight_documents.xml'],
    'ops:Label_File_Info.ops:md5_checksum': ['a366a14158f5a7f0dc7a1b4c06c003ae'],
…
}

Something changed, and rather than pds.api_client shielding its users from that change, it passes the change onto them 😮

The new properties attribute is no longer a list of values, but a dict with a single values element with a list of values:

{
…
    'ops:Label_File_Info.ops:file_ref': {'values': ['https://pds-gamma.jpl.nasa.gov/data/pds4/test-data/registry/urn-nasa-pds-insight_documents/bundle_insight_documents.xml']},
    'ops:Label_File_Info.ops:md5_checksum': {'values': ['a366a14158f5a7f0dc7a1b4c06c003ae']},
…
}

So to make sure the fix to #106 actually worked, this PR also absorbs and deals with the change in data coming from the API server.

Update: now the server always gives sequences of values for properties but without the single-item dictionary with a values key—even for those which are semantically singly-valued, like label file MD5. Also, this works around PDS API Client stealing the pds package name and preventing dependent code from being found.

🩺 Test Data and/or Report

$ venv/bin/python setup.py test
…
running test
…
----------------------------------------------------------------------
Ran 20 tests in 0.678s

OK

🧩 Related Issues

• Improvements per API updates to remove workarounds from code #106
• error 500 on GET /collections/:lidvid:/products registry-api-service#17
• Multiple values for ops:Label_File_Info.ops:file_ref and …:md5_checksum registry-api-service#49

[collinss-jpl]

👍

[jordanpadams]

@nutjob4life would this work with the previous implementation of the API as well? That is the way the response format should be, so as long as it works for both, we should be ok.

[nutjob4life]

would this work with the previous implementation of the API as well? That is the way the response format should be, so as long as it works for both, we should be ok.

@jordanpadams no, it won't.

Some would say it's the job pds-api-client to provide a uniform/stable interface to application programmers regardless of what comes across the wire, though 🤔

[jordanpadams]

@nutjob4life copy. then please revert the changes to support the new "values" dict. that should not be there and is a regression to the API. one of the fun parts of working from a beta version of an API without a robust regression suite :-)

[nutjob4life]

@jordanpadams okay, reverted 😉

[jordanpadams]

@nutjob4life do we still need --disable-pagination-workaround?

[nutjob4life]

@nutjob4life do we still need --disable-pagination-workaround?

@jordanpadams that's covered by #107

[nutjob4life]

@jordanpadams good catch on the Versioneer stuff in setup.cfg 🍻