This page is for Service Fabric internal developers who are adding commands that take dependency on a not yet released version of the python SDK.
Setting Target to Unreleased Python SDK
If your change / addition for the Service Fabric CLI takes dependence on unpublished Swagger specs, then you will have to configure both your local machine and Github Travis CI to target the newest python SDK (generated from Swagger) for testing and validation. You will need to set target separately for your local machine and Travis CI.
Do not make changes to the generated SDK. The SDK uploaded to the customSDK folder in the repo will be removed prior to each release. Testing and validation will be performed against the released SDK prior to publication, so any changes in customSDK will be lost and validation will fail.
Setting target on local machine
The easiest way to set up for internal development work is to complete the regular setup steps. After following those steps, swap out the downloaded Python SDK with one containing the changes you want to test against. To swap:
- Build the version of Swagger containing the changes you want.
- Copy the Python SDK generated into the environment folder of your virtual environment.
The generated Python SDK from Swagger can be found in the out folder. It should be at
out\debug-AMD64\swagger-sfclient\<swagger-version>\python_sdk\azure\servicefabric.
Copy everything inside the swagger out\debug-AMD64...\servicefabric folder into the site packages of your virtual environment. The site packages should be located at path (from root):
<your-environment>\Lib\site-packages\azure\servicefabric. You can delete all items in
the servicefabric folder, including the cache folder, prior to pasting your SDK.
If you do not find the site packages being used by sfctl in the location mentioned above, or if you don't see your changes reflected, you can verify the path by running pip show azure-servicefabric which will show you where the package is being loaded from. Once you have that location, replace the package there instead.
After swapping, you can follow the instructions add a new command as normal.
Do not make changes to the generated SDK.
Setting target for Travis CI
If this step is needed for development, it means that the Travis CI checks will fail using the public python SDK. To get around this issue, copy the SDK from the swagger out folder into <root>/customSDK. The path should then contain <root>/customSDK/servicefabric/service_fabric_client_ap_is.py.
Travis CI will pick up this uploaded custom SDK if there is an 'Unreleased' section in the README file.
Check in changes for the custom SDK in a separate PR to keep clutter low.
Documenting
All public facing documentation should be placed in the help files rather than as function docstring. Avoid copying the help documents directly from service_fabric_client_ap_is.py.
- Development
- How-To
- Details
- Service Fabric Developers