eak24

openapi: 3.0.2
info:
  title: OAI Specification example for Polymorphism
  version: 1.0.0
paths:
  /pet:
    get:
      responses:
        '200':
          description: desc

eak24

{"openapi":"3.0.1","info":{"title":"Onshape REST API","description":"The Onshape REST API consumed by all client.\n# Authorization\nThe simplest way to authorize and enable the **Try it out** functionality is to sign in to Onshape and use the current session. The **Authorize** button enables other authorization techniques. To ensure the current session isn't used when trying other authentication techniques, make sure to remove the Onshape cookie as per the instructions for your particular browser. Alternatively, a private or incognito window may be used. Here's [how to remove a specific cookie on Chrome](https://support.google.com/chrome/answer/95647#zippy=%2Cdelete-cookies-from-a-site).\n- **Current Session** authorization is enabled by default if the browser is already signed in to [Onshape](/).\n- **OAuth2** authorization uses an Onshape OAuth2 app created on the [Onshape Developer Portal](https://dev-portal.onshape.com/oauthApps). The redirect URL field should include `https://cad.onshape.com/glassworks/e

eak24

OpenApi Generator Runner

Motivation

openapi-generator offers 50+ clients, but very often those clients don't work "out of the box" with a real-life OpenApi specification. Often one has to use template customization or custom commands and options to make the clients work. In drastic cases, a user may have to even add plugins to the generator. Furthermore, once the generator is designed, the user is obligated to test the client code with real use cases, which often involves writing a lot of custom code per client. This can become quite a management challenge - and in my case has prompted the development of a tool that can download the openapi, generate the clients in a folder nearby sometimes using templates to customize the authentication process, and test the result. Setting up this process has been a surprisingly long and arduous process, and I can only imagine that others have found themselves in a similar situation.

Proposal

I'd like to build an openapi-generator-runner that can read an `x-open

eak24

openapi: 3.0.1
info:
  title: Test additional properties with ref
  version: '1.0'
servers:
  - url: 'http://localhost:8000/'
paths:
  /ping:
    post:
      operationId: ping

eak24

RELEASE=jhub
    NAMESPACE=jhub

    helm upgrade --install $RELEASE jupyterhub/jupyterhub \
      --namespace $NAMESPACE  \
      --version 0.7.0 \
      --values config.yaml --dry-run --debug
    [debug] Created tunnel using local port: '57299'

    [debug] SERVER: "127.0.0.1:57299"

eak24

{% macro render() %}{% include "ET.yaml"%}{% endmacro %}

# inputs which will be passed in explicitly later: OD_ent_pipe, q, temp, depth_end

{% set L_ET_max = opt.L_ET_MAX %} # optional input
{% set SDR_drain = 26 %} # materials database

# calculate drain diameter
{% set OD_drain = ent.drain_OD(q, temp, depth_end, SDR_drain) %}

eak24

#Author-
#Description-

import adsk.core, adsk.fusion, adsk.cam, traceback

def run(context):
    ui = None
    try:
        app = adsk.core.Application.get()
        ui  = app.userInterface

eak24

- This:
    is: some
    very: basic
- YAML

eak24

flow: {{ flow }}
SDR: 26
hl: !u 20*u.cm

eak24

import pint
import yaml
u = pint.UnitRegistry(system='mks', autoconvert_offset_to_baseunit=True)

def units_representer(dumper, data):
    return dumper.represent_scalar(u'!u', str(data))
yaml.add_representer(u.Quantity, units_representer)

def units_constructor(loader, node):
    value = loader.construct_scalar(node)