Add missing Python wrapper for SetCustomExcite

[oberstet]

This is a follow up of https://github.com/thliebig/openEMS/pull/129/, see comment https://github.com/thliebig/openEMS/pull/129#issuecomment-1858768691

[oberstet]

alright, PR is here https://github.com/thliebig/openEMS/pull/134

2 questions:

---

is there a versioning policy?

I mean, yes, it seems to be "semver" .. but how exactly for dev versions?

./CMakeLists.txt:set(VERSION "v0.0.36")
./python/setup.py:  version = '0.0.36',

dev versions for semversioned packages usually use something like

23.1.1
23.1.1.dev1

either that, or with an additional v as prefix.

"official" Python docs:

https://peps.python.org/pep-0440/ https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers https://packaging.python.org/en/latest/specifications/version-specifiers/#developmental-releases

further semver docs:

https://semver.org/

---

unfortunately, it seems there is an issue resulting from a recent commit on master (which I synched before creating this PR) leads to an issue

ahh, right;)

yeah, I figured this out just minutes ago and built with master CSXCAD - which does work.

however, I have not tested using Python code and custom function ... sorry, I don't have custom functions in the required syntax .. not example ..

[thliebig]

The version policy is surely up for debate as I never gave it much though. Usually I release a version with a given number, currently 0.0.36 and then after a few more changes openEMS reports itself like this: openEMS 64bit -- version v0.0.36-12-ge5db9de which means 12 commits ahead of v0.0.36

But I'm not sure that this answers your question?

[oberstet]

The version policy is surely up for debate as I never gave it much though.

ok, no problem, I understand.

however, from my perspective:

versioning policy is as important as CI/CD or APIs or documentation or LICENSE or etc

it is stuff beyond mere code, and it's crucial for a SW package that can be trusted and depended on

and it has many facets and questions related - which can be answered in different ways, but should be answered in my opinion.

again, I am not critizing .. just trying to get a clue about perspectives/interests

---

let me just give 1 example:

assuming there would be an argued/principled, and conscious decision for semver, even then semantic versioning is more than just a syntax rule.

for example, usually, the position of the changed digit signifies whether an interface break is part of the version or not. and this is for actual releases, not even talking dev versions.

e.g. moving from 0.36 to 0.37 would usually (likely) be read:

no binary breakage. (usually there is at least 3 digits for semver'ed packages ..)

so in the case of openEMS being partially native code, my binary executable is guaranteed to run without any change on my side. binary compatibility while upgrading *.so's

this requires specific care with headers and types with C++ in general, and templates specifically, and might be impossible in most cases. even plain old OO style C++ has no ABI. this is different from C. anyways, there are many details.

should that probably be another discussion at https://github.com/thliebig/openEMS-Project/discussions/ ?

[oberstet]

But I'm not sure that this answers your question?

independent of the general question, my concrete question rgd this PR: do you want me to change either/both of C++/Python version in the PR, and if so, to what values?

[thliebig]

This PR/issue has nothing to do with any versioning issue/ideas for improvement...

[thliebig]

The PR is merged, thus I think this can be closed