Proposals:

• spark-python
• sparkclient-python
• pyspark
• sparkpy

This is definitely worth discussing. My thoughts on this item were this:

• The intent of this project is to produce a package that will be posted on PyPI, so the fact that it is a 'Python' package is implicit.
• It is also our intent to produce two packages: a simple and lightweight API wrapper (this 'ciscosparkapi' package) no thrills just encapsulates the API, and an SDK package that adds additional functionality above and beyond wrapping the API - the 'ciscosparksdk' package.
• As for the name, I was going for something short, simple and searchable that delineates the API wrapper from the SDK package. So, it needed to contain 'cisco' + 'spark' + 'api/sdk'.
• As for searching on GitHub... The repo should show up as a Python package, and we can change the tagline to clarify if needed.

Given that information... Your thoughts on the naming?

As there will be other spark sdks and wrappers hosted on devnet, I think we cannot avoid adding a py or python mention,
Moreover, the name should make it clear this sdk is not an official cisco spark SDK (ie, provided by the Cisco Spark and Spark 4 Developers teams)

Concerning the other library you're planning, defining a scope will help differentiate from this library.

Thoughts sumup for the naming :

• should contain python or py
• should contain client or wrapper (not api)
• should contain spark rather than ciscospark

I see where you are coming from. My reason for including 'cisco' in the designation was to aid in searching and to differentiate it from other unrelated 'spark' packages. Just run pip search spark sometime and you will see what I mean.

I certainly wouldn't want to compete or misrepresent the package, as the Cisco 'official' SDK. I talked with the BU before starting this project (I had already written one Spark API SDK, why start another one if the BU is going to release and manage their own), and long-story-short they didn't have any immediate / short-term plans for releasing a Python SDK. My hope here was that if we could get a good community effort going here on DevNet with well structured and complete code, it could perhaps become the basis for a BU managed SDK in the future.

I am certainly open to name suggestions here. However, I can say that so far I don't really like any of the permutations as much as I do the current naming.

• pysparkwrapper
• pysparksdk (I don't hate this one, but I don't really like it either)

I don't realy like 'client' (especially for the API wrapper package) because we aren't providing a Python-Spark client, just essentially the API's modeled as simple and native Python objects.

spark-a-py ?

ciscosparkapy ?

I haven't seen any compelling reason or better alternative name for this package, so I'm closing this issue for now. I'm glad to reopen this discussion if new recommendations or motivations arise.