Possible code compatiblity breaking changes for future-proofing and performance improvements

[gfrn]

A few suggestions that may result in incompatibilities in the future and should be discussed:

• Only accept byte strings in the client library to avoid unnecessary conversions
• Move from multiprocessing queues to more efficient queuing methods
• Return a bytes object instead of a array of chars on request() and read()
• Remove VERSION file and move towards semantic versioning patterns
• Remove Makefile and utilize single-line pip commands instead

Non-breaking changes:

• Add type hints whererever possible
• Translate all documentation to English
• Rename constants (ALL_CAPS_PEP_PATTERN)

[anacso17]

Hi @gfrn, about the points raised here, I think some of them can be extended to other python packages (siriuspy, and others). The idea of using implementations with the same pattern make later maintenance easier.

Specifically about Makefiles, I believe they are friends, they bring the standard/recommended way of using pip commands, which sometimes are not familiar to the user. In any case, having the Makefile does not exclude the possibility for the user to directly use pip commands. So I prefer to keep them.

About the VERSION file, I didn't understand the suggestion. Could you please give an example?

[gfrn]

Hi @gfrn, about the points raised here, I think some of them can be extended to other python packages (siriuspy, and others). The idea of using implementations with the same pattern make later maintenance easier.

Specifically about Makefiles, I believe they are friends, they bring the standard/recommended way of using pip commands, which sometimes are not familiar to the user. In any case, having the Makefile does not exclude the possibility for the user to directly use pip commands. So I prefer to keep them.

About the VERSION file, I didn't understand the suggestion. Could you please give an example?

Good morning!

As for the version, we currently use a single version file for both the server and client, and for both to be compatible, an exact match is expected (MAJOR-MIN-PATCH).

That version is held in a VERSION file which is shared between both scripts, while the norm would be to have different versions, each one declared in either a __init__.py file or in separate VERSION files, which would allow us to improve server/client code individually and keep version milestones separate. I do prefer setting it in an __init__ file as that would keep it easily accessible during the module's lifetime while avoiding unclear version assignments through redundant files.

Since we would be doing different versions for each script, following a semantic versioning scheme would be preferable, as that would allow us to determine if versions are compatible at a quick glance. For example, versions 2.1.1 and 2.2.0 are compatible, but 2.1.1 and 3.0.0 aren't.

Semantic versioning states that:

• MAJOR (X.0.0) version changes introduce breaking changes and require reworking existing code for applications (IOCs, client/server applications)
• MINOR (0.X.0) version changes introduce new features while retaining compatibility with existing code
• PATCH (0.0.X) version changes fix/improve existing functionalities while retaining compatibility with existing code

We can keep the VERSION files if that makes things easier, too.

As for the Makefiles, that does make sense, so keeping does seem like the most sensible option now.

Thanks for the input!