Build fails due to unpublished pybabel package on pypi

[tjsr]

Describe the bug
The pybabel package is no longer available on pypi, therefore the build fails when trying to download and install requirements. The replacement published babel uses a different module format and command argument syntax, so the existing babel commands also fail if trying to use that replacement package without changes.

To Reproduce
Steps to reproduce the behavior:

1. Build the project using .\compile.ps1 -setupenv then .\compile.ps1 -all -everything or the equivalent bash scripts.
2. Alternatively, re-build the project using the GitHub actions.

Expected behavior
Compile succeeds through to end and produces output development executables.

Additional context
A patch for this has now been written and is currently being tested and merged in.

[tjsr]

A fix for this is available at tjsr#9 - I'm trying to figure out how best to create a PR so this can be merged to the diverging master branches in both repos.

[tjsr]

@esitarski I've noticed you've committed a variant of this to the dev branch but have omitted the changes to the -l parameter.
The updated pybabel command format has changed - this switch now wants just the locale identifier, not the path to the locale files, which is why you're experiencing the build failure during the workflow run at https://github.com/esitarski/CrossMgr/actions/runs/12993634675/job/36236291139#step:6:2038

That's also why I've had to derive this value to pass as that parameter.

[esitarski]

Yes, the root cause was that the pybabel team introduced some breaking changes. They also changed the name of the module from pybabel to babel, but kept the command-line as pybabel. The only purpose of pybabel is to convert the .po files to .mo files. This is a lot of hassle given that there are only three of these, and babel is a poor choice as it does a lot more. There is a more efficient module (polib), which can be called from a python script (something that is difficult from babel, for some reason). I will be incorporating this soon and eliminating babel entirely. On another note, I didn't do the initial github workflow work, nor the "compile" scripts. Although I appreciated the contribution, the decision to have two versions on the scripts (one in bash and the other in PowerShell) was a poor one. It is possible to have one relatively platform independent build script in python alone. When platform specific actions are required, the logic could be clearly seen in one script. It would eliminate the "cognitive load" of dealing with bash and PowerShell (python only). It would make any platform-specific logic accessible and easier to maintain. And, python has much richer functionality for the command-line.

…

On Mon, Jan 27, 2025 at 4:21 PM Tim Rowe ***@***.***> wrote: @esitarski <https://github.com/esitarski> I've noticed you've committed a variant of this to the dev branch but have omitted the changes to the -l parameter. The updated pybabel command format has changed - this switch now wants just the locale identifier, not the path to the locale files, which is why you're experiencing the build failure during the workflow run at https://github.com/esitarski/CrossMgr/actions/runs/12993634675/job/36236291139#step:6:2038 That's also why I've had to derive this value to pass as that parameter. — Reply to this email directly, view it on GitHub <#148 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGXKMJEFMRCDCXHMCUKVT2M2PMNAVCNFSM6AAAAABV35NVY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJWHEYTSNRRHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Edward Sitarski

[tjsr]

It is possible to have one relatively platform independent build script in python alone.

Okay - well let's create an issue, and break that down in to some tasks so people can work on it in bits. There's probably a lot of common compile things that can be started so that the current .sh and .ps1 script call that common python portion of a build, and over time we can migrate that in.
My expertise is in building Apache Ant builds for Java projects, I'm not a big Python person so I'll have to do a bit of looking in to Python build systems, but once I get past some of my other priorities for features/fixes I can look at that, as build workflow stuff will improve my developer experience. I've already spent the effort building a Dockerfile for the build - but this still needs a bit of work and testing.

On of my next tasks is going to be to add caching to the github builds and allow it to build in all develop/* and fix/* branches, as a 25 minute build is ridiculous for what it's currently doing.
That will also include having it not need to build SeriesMgr and other projects in every build - but that's a low-priority todo for now.

The other things that take priority is fixing the Ultra decoder read/connection code, then finishing refactoring things in to a TimingDevice framework. This will enable future work on technology-agnostic input sources and multiple time/crossing points - more on that later.

Priority 2 is then to get Teams Racing functionality added for GMBC usage - enabling relay teams in lap-based events to be calculated in results.

[esitarski]

Fixed in latest. Removed pybabel, replace .po to .mo compile with polib and python script.