LabGym version if running a customized LabGym

[ruck94301]

The 2.9.6 uses schema 'context 2025-08-10',

which lets us report like

  17 2025-09    User started LabGym 2.9.3 with Python 3.10.18
   5 2025-09    User started LabGym 2.9.5 with Python 3.10.11
  11 2025-09    User started LabGym 2.9.6 with Python 3.10.0
 358 2025-09    User started LabGym 2.9.6 with Python 3.10.11
   7 2025-09    User started LabGym 2.9.6 with Python 3.10.12
   1 2025-09    User started LabGym 2.9.6 with Python 3.10.14
  16 2025-09    User started LabGym 2.9.6 with Python 3.10.16
  73 2025-09    User started LabGym 2.9.6 with Python 3.10.18
   1 2025-09    User started LabGym 2.9.6 with Python 3.10.4
   6 2025-09    User started LabGym 2.9.6 with Python 3.10.8
   5 2025-09    User started LabGym 2.9.6 with Python 3.10.9
  20 2025-09    User started LabGym 2.9.6 with Python 3.9.13
  10 2025-09    User started LabGym 2.9.6 with Python 3.9.23

Why are we seeing starts of 2.9.3 and 2.9.5?
Must be due to starts of development variants, customized LabGym.
Like maybe branched from genuine 2.9.3 or 2.9.5, but with the feature branch for centralized logging merged in.
Just Henry or Bobby?
My work in progress is all updated with 2.9.6, so those aren't me.

Some ideas re improving the startup context report.
Not sure if they are good ideas or bad ideas.
Consider and comment?

1. Startup could "hash" the LabGym tree (except datafiles) and if the tree is "tainted", indicate so with a short hash. "version": "2.9.6+4b35". Hashing is fast, btw, I think performance is not a concern. This hash is not a commit hash, btw.
2. Actually, LabGym.version might ought to be more aware... the short hash could be moved to the version definition instead of the context reporting. That's better, I think.

Either way, there's a small complication in implementation. The "reference" hash has to be stored, after the version is frozen, but stored in a way that the reference hash itself doesn't affect the hash. This complication can be easily handled though.

[yujiahu415]

Sorry, I'm not sure what this means. Can you elaborate a bit more on what you would like to do? v2.9.3 and v2.9.5 was released but they have critical bugs or errors. So, these two versions have been deleted.

[ruck94301]

We are gathering stats from user starts.
Some of those are genuine users, using genuine released LabGym.
Some of those are Henry/John/Bobby, that is, developer starts, with NOT-released sw, which distorts the stats.
I am suggesting that LabGym, when announcing its version, do so in a way that reveals if it's "unofficial" code.

For example, the v2.9.3 and v2.9.5 MUST be reporting developer starts with modified sw (NOT genuine user starts with officially released sw).
We know this because the central logging feature isn't generally available until 2.9.6.
The only way that v2.9.3 or v2.9.5 get reported to the central-logging receiver (google cloud),
as shown above in September,
is from running a branch that still used an old init.py (where version is defined) with the central-logging feature branch merged into it. That must be by Henry or John or Bobby, right?

Anyway, I'm trying to say that if a sw is a modified version of a released LabGym, in a perfect world it wouldn't persist in claiming to be the genuine released version.

If user reports an issue with version 2.9.6, it gets investigated. If user reports an issue with version 2.9.6+4b35 (or whatever hash), you say "Andrew, it looks like you're using a customized version of the sw. Can you reproduce your problem with an official release? That info will help!". Because you don't want to put energy into chasing something that isn't LabGym.

This isn't a user-facing issue or improvement. It's a modest improvement to stats collection.

[yujiahu415]

Oh I see. Thanks for the detailed explanation! That makes sense.

[yujiahu415]

And are you going to address this?

[ruck94301]

sure, I'm willing to do it, as long as you are open to it.

If you end up thinking it's unwelcome, then no worries, but pls let me know.
I figured that making it a GitHub "issue", before putting effort into the code and the PR, is helpful.

It's actually good that you challenge it and ask me to defend the idea! Also, by dialoging on it, as an issue,
there's always a chance that a better implementation might result, because sometimes the discussion reveals that I've overlooked something.

[yujiahu415]

Yes, please help with this. This is nice to have to ensure the efficiency of troubleshooting in the future. Many thanks!

[ruck94301]

(Sorry, this should have been a GitHub "Discussion" instead of a GitHub "Issue". I'll be more careful going forward.)

I have implemented a version-embellishment which is based on the signature of the LabGym py-files.
(I have not PR-ed this feature, because I'm ambivalent about a design decision, see below. I suppose I could PR it and discuss in the PR, but I have not done so.)

version-string examples

1. naked-version example
   2.9.7
2. version+shorthash example
   2.9.7 (8d21)
3. version+longhash example
   2.9.7 (8d215185211249bb8ee70dbc6cf84de7)

As implemented in my feature branch,

• user-facing version display:
  • when the signature of py-files is different from that of the released py-files, then the user-facing version display is version+shorthash, like 2.9.7 (8d21)
  • when py-files are as-released, then the user-facing version display is naked-version, like 2.9.7 (like existing behavior)
• the version reported via central logger to the central logging receiver is version+longhash, like 2.9.7 (8d215185211249bb8ee70dbc6cf84de7) whether LabGym py-files signature matches the lookup or not. This logging is not user-facing.

NB: To make this work right, each time a release is prepared, the releaser has to update LabGym/pkghash/versions.toml
with the new version+longhash. If this step is inadvertently omitted, then the user-facing version display would be version+shorthash, whether LabGym is genuine-released or customized.

(?) Design Decision...
Is the benefit (of suppressing the shorthash) worth the ongoing cost?
I'm now thinking "keep it simple".
Remove the lookup. Remove the extra and the updating of the lookup-table (versions.toml) in prep for each release. Let user-facing version string be either (a) always naked-version 2.9.7 (same as before), or (b) always new version+shorthash 2.9.7 (8d21).

I do think that reporting version+longhash via central logger to central logging receiver is a solid benefit, so after this discussion I expect I will PR a variant of this feature implementation.

Thoughts?

[yujiahu415]

I prefer the option of always naked version (e.g., v2.9.7).