Streamlining for pypi packaging

[erikbosch]

This is related to #75

Packaging vss-tools to PyPi has some advantages, like easier to get tools without need to clone. It could also be a starting point for us to refactor tooling to make it easier to create your own tools. This PR basically just changes version handling as I had problems getting the current one to work for publishing to PyPI. There are some specific rules on versions in PyPI, so I am proposing a possible version naming guide.

What I would like to discuss:

• Anyone currently using or in the near future intending to use PyPI packaged vss-tools
• What do we intend to include in a package? At least some tools like vspec2binary are a bit cumbersome to package as it depends on a binary lib (i.e. not only package) Including "all" tools also might make the package big due to dependencies
• I.e. would it be beneficial to rather have more packages, like vss-tools-core, vss-tools-protobuf, vss-tools-graphql and so on?
• Or do we first need to refactor vspec2x.py to make it more generic, so that it in itself is unaware of what exporters that exist and only imports the one that actually is used.

Input is welcome

[SebastianSchildt]

I think having a Pypi package would make things a lot easier for "users", and we would have an implicit versioning (we might still need to figure out how to that "exactly" but at least form a user perspective you can always point them to a specific pypi version instead of saying "that tag, hash, submodule reference")

I would go for "less" packages in the first step, just to avoid maintaining so many different package metadata. For vpsec2binary it is a bit challenging, because while you CAN build and then push, the question is how to handle at least ARM and AMD, and it would be bad if some guy on ARM can't use the tools even though he does not need the binary converter at all just because we did not put up a correct wheel. Also it has no real build system, so making it build when installing pypi from source also takes some effort (which we would need anyway, because maybe they are MUSL vs GLIBC users, QNX users etc.), and we can't build for everyone.

Wrt. to adding exporters without touching the core (e.g. the ability to "load plugins", hooking into vspec2x), I would see as a seperate issue

In summary

• lets have Pypi package. I think it is immediately helpful for some
• for practical reasons put Py only stuff
• Find a solution for vspec2binary
  • maybe DO make a separate package, limit it only for amd64, "let people know"
  • Rewrite in python? Not sure that is technically feasible/useful
  • Handle "having a Plugin/Hooking mechanism vspec2x" as separate issue/feature request

[erikbosch]

Now this seems to be functional. Remaining work concerns:

• Create vss-tools on "real" PyPI index
• Describe governance in wiki
• Find at least one more PyPI-maintainer. Adding @SebastianSchildt is easy as he already have a PyPI account. But if we have someone more in VSS with pypi account (or willing to create one) that would be great, so that we have multiple persons as backup. Possibly @paulboyes as official COVESA representative.

[erikbosch]

Closing this one, actual merge through other PR