AguaClara / aguaclara

An open-source Python package for designing and performing research on AguaClara water treatment plants.
https://aguaclara.github.io/aguaclara/
MIT License
25 stars 13 forks source link

Python/Onshape Integration #201

Open oliver-leung opened 5 years ago

oliver-leung commented 5 years ago

We need to integrate Ethan's onshape_client package to reach the following goals:

  1. Send data from Component objects into Onshape Part Studio/Assembly configurations.
    • In order for someone to pass data from Python into Onshape (from a Colab notebook or their local computer), they need to create an access key and secret key for their Onshape account, then pass it into onshape_client for authorization. Our two potential methods of achieving this are:
      1. Requiring users to enter their access/secret keys in Python
      2. Requiring users to save a .onshape_client_config.yaml in their home directory (local) or in GDrive (Colab)
      3. Creating a shared AIDE Onshape account, whose access/secret keys are built into the aguaclara package and are used whenever the package is imported.
  2. Utilize the new Super Derive feature in Onshape to propogate configurations into subcomponent Part Studios/Assemblies.
    • Two changes we must make to our JSON serialization methods:
      1. Component.write_properties_to_file(filename) should overwrite the file if filename already exists.
      2. In the JSON, if the key is a component, then the value must be a string representing a dictionary, not a dictionary itself.
oliver-leung commented 5 years ago

I've run into a strange error which I've detailed here, preventing me from creating a Python object from an Onshape Part Studio. Aside from that, I think that I have the process complete for authorizing Onshape in Python.

oliver-leung commented 5 years ago

The docutils version error has been resolved, so we can likely unpin it from Pipfile.

oliver-leung commented 5 years ago

The error that I mentioned above (preventing me from creating a Python object) has been resolved due to an incorrect .onshape_client_config.yaml - tag me if you need to see what the corrected one is.

A discussion with @ethan92429 has revealed the following divine truths:

  1. Given the URL to an Onshape element, and a dictionary containing a custom configuration of that element, we can deterministically map that dictionary into an encoded string using urllib3. We can then append the string to the element URL, creating a custom configuration URL that is publicly-accessible.
  2. onshape_client requires Onshape credentials to instantiate the client, in order to access the API.
  3. The API is actually not necessary to create custom configuration URL's. Instead, they're mapped using the strategy mentioned above with urllib3.

For our purposes of creating custom configurations, it then becomes clear that we actually don't need onshape_client for our Onshape use case. Instead, we should be using the following strategy:

  1. Compile the necessary design outputs in a configuration dictionary.
  2. Map the dictionary to an encoded string via urllib3
  3. Append the encoded string to the element URL and give it to the user.