Improve Package Versioning

[CEXT-Dan]

Currently, I use GitWCRev to generate version using $WCLOGCOUNT&65535$, which should have been $WCLOGCOUNT+1&65535$ because its off by one.

There’s a C++ project (Version) that generates a C++ header file (from pyrx_version.tpl) that's the picked up by the compiler
The version project also generates __init__.py (from __init__.tpl)
The templates are stored in the templates folder and are copied into their proper places.

This procedure can change, however it must be - automated - in that it generates versioning for C++ and Python
GitWCRev could be replaced with a bat file or something that Visual studio can execute

Versioning and checking

IMO, this not a correct approach
PyRx DLL version (2.2.19.4585.20250723) does not match the source version (2.2.19.4587). Some features may not work as expected

Originally, I had
MAJOR MINOR REVISION BUILDDATE

We changed it to
MAJOR MINOR REVISION GITLOGNUMER BUILDDATE

As far as I’m concerned, anything after the revision is for developers, so for version checking

Better
PyRx DLL version (2.2.19) does not match the source version (2.2.19). Some features may not work as expected

[CEXT-Dan]

Though I can imagine future releases that will contain only Python functions (but that's for later).

They way I see it,

• Every CAD company makes releases on a different cycle
• I have 100s of bug reports outstanding
• I probably have 100s of bugs yet to be discovered

So, while it’s true that C++ development will slow, there will always need to be a versioning match if we are to continue to publish both C++ and python in the same package, otherwise versioning will be too hard to maintain.

[gswifort]

I added the version.py file.
Calling python Version\version.py results in the version being displayed on stdout in the format 2.2.19.4587. I don't know what the .bat script is supposed to do: should it just display the version or should it write it to a file?

[gswifort]

it has to generate the C++ pyrx_version.h header

so I just have to overwrite these values?

#define VERSION_MAJOR 2
#define VERSION_MINOR 2
#define VERSION_BUILD 19
#define VERSION_REVISION 4585

[CEXT-Dan]

so I just have to overwrite these values?

Yes, only VERSION_REVISION before the build starts, now GitWCRev is executed as a pre compile script. Hence the idea of using .BAT file

__init__.py doesn't need to be generated

Fine, as long as you can guarantee the compiled version exactly matches

[CEXT-Dan]

this is the generator I'm using now

GitWCRev "$(SolutionDir)\" "$(SolutionDir)Templates\pyrx_version.tpl" "$(SolutionDir)pyrx_version.h" 
GitWCRev "$(SolutionDir)\" "$(SolutionDir)Templates\__init__.tpl" "$(SolutionDir)pyrx\__init__.py" 

[gswifort]

I updated version.py to generate pyrx_version.h. The version is determined by the same function that setuptools_scm determines for __init__.py. The bat file must contain python -m Version\version.py

[gswifort]

I will remove this, if anyone installs it from source they should be aware of unexpected behavior.

[gswifort]

Better
PyRx DLL version (2.2.19) does not match the source version (2.2.19). Some features may not work as expected

I'm not sure if I understand correctly. If the versions don't exactly match (commit level), should a version mismatch be printed without specifying the exact version? At first glance, it looks like 2.2.19 is equal to 2.2.19

[CEXT-Dan]

My point is 2.2.19.4585.20250723 or 2.2.19.4587 is not the version, 2.2.19 is the version
4585.20250723 and 4587 should be disregarded, this if only for support requests, so I can look up the build date

[gswifort]

Okay, but I still don't know what message (and if any) I should display to the user. I assume that the release versions will be compatible; this message should only appear when installing directly from the source, except for "fresh build" commits.

[gswifort]

Remove this warning?

[CEXT-Dan]

It’s up to you, maybe have a tolerance +- a few versions
Maybe someday we can add a py_check_for_updates command

[gswifort]

I think pyrx_version.h shouldn't be present in the repository, It's generated and only needed for compilation time..?

[gswifort]

I sometimes need to make builds that are outside the realm of GitHub, in this case, I manually set a private version

How? What number?

[gswifort]

I sometimes make refresh build in the trunk; I don’t do anything as the version project handles this.

It seems that this would also be the case here.

[CEXT-Dan]

I already added the n+1 if that was the issue

[CEXT-Dan]

$WCLOGCOUNT&65535$, which should have been $WCLOGCOUNT+1&65535$

[CEXT-Dan]

I would rather use your tool instead of the project being dependent on tortoise git
I just just need to understand the workflow, and make sure it fits with my needs

[CEXT-Dan]

I would like to manually set the MAJOR MINOR REVISION and not use a tag
pyrx_version.h can be ignored at some later date
then I call version.py from visual studio
is this okay?

[gswifort]

In the local repository, yes. Unless you call python -m build or pip install ... the version will not change. I don't know if this is important to you. Is there any scenario where you need to check pyrx.__version__? I think it's only useful for installing and reporting bugs.

[gswifort]

But I could probably update pyrx/_version.py (the __init__.py file imports the __version__ value from this file) when calling Version\version.py. I'll have to check if setuptools_scm provides a separate function to create the _version.py file

[CEXT-Dan]

What effect if any, would this have if someone wants to distribute via embedded as discussed here
#171 (reply in thread)

I suppose it would just be the version they installed?

[gswifort]

Yes, once installed the version will not change. So it has no impact.

[gswifort]

Done. Updated PR.

[CEXT-Dan]

we can merge this after the next release, so gives me time to kick the tires and try to break it

[CEXT-Dan]

So, I don’t like the idea of having different systems setting the version numbers, no doubt this will cause issues down the road
I thought it was only the VERSION_REVISION (4611) that would update with version.py and that would cover all files that are versioned
I would like to be able to set the 2.2.22 part in a single place, and have version.py set the 4611 when I create the release (compile)

[CEXT-Dan]

Command: PYRXVER
PyRx version <2.2.22.4611.20250801> loaded:

2.2.22.4611

Should match across all versioned files, do you agree?

[gswifort]

Yes. Done.

[gswifort]

Part of the conversation here: 89398df

[gswifort]

I think you should rollback these commits. I've already done what you were trying to achieve here. The version for pyrx_version.h and __init__.py is set in one place - in the version.txt file

[gswifort]

is set in one place - in the version.txt file

I need to push one more commit that's waiting in my repo, but first you need to "fix" the repository on GitHub

[gswifort]

25914cc

That wasn't my goal. The revision number was supposed to be unique for each commit, not for each build. I did what you asked – MAJOR, MINOR, and BUILD are set manually. REVISION is overridden in the __init__.py file for each commit (specifically, it's created during installation) and for each build (+1 is added during compilation), and in pyrx_version.h for each build (+1 is added).

[gswifort]

REVISION is overridden in the __init__.py file for each commit

Without a properly configured setup.py file we won't achieve this.

[CEXT-Dan]

Sorry, I modified it slightly so the version is set by the compiler.
I'm making a test release now

[gswifort]

the version is set by the compiler.

I don't know how it works, but I think it would be enough for the compiler to overwrite the version.txt file

[CEXT-Dan]

This seems to work well, I know it’s not what you had intended, but I think it’s easier for my workflow
The compiler calls your version.py, then sets up __init__.py, pyrx_version.h and PackageContents.xml
Versioning for all files is setup in one place, well except for PyRxAcSetup, as I have to update the GUID

[gswifort]

These solutions aren't mutually exclusive. Have you already done what you wanted? I'll fix it so it works for me too.

[CEXT-Dan]

yes

[gswifort]

except for PyRxAcSetup, as I have to update the GUID

Are the GUIDs randomly generated by you? If so, you can do this in the version.py file and cache it.

[CEXT-Dan]

We seem to be going around in circles on this.

If you insist on having __init__.py version being set by a workflow. Then I would drop the VERSION_REVISION from the compiled sections. So, the .DLL version is just 2.2. 23.0 in the windows properties, and I can drop that value from PYRXVER command, so it would appear as PyRx version <2.2.23.20250803>

Ap.Application.pyrxVersion() would be 2.2.23.20250803

I’m used to working with the build date with regards support requests

[CEXT-Dan]

a08de11

• Remove Github generated versioning from C++ compile
• ApApplication.pyrxVersion is now ApApplication.pyrxDLLVersion
• command pyrxver is now pyrxdllver
• onload version is removed, version could be moved to _host_init.py

[CEXT-Dan]

Maybe this will help separate python code versioning from C++. I.e. Python library sections depend on DLL version 2.2.23 or later
Then we can explore making python only releases. I will make a new release build for you to test

[CEXT-Dan]

BTW, what do I need to do so you can publish to pypi? Or can you already?

[gswifort]

I'd probably need to be able to create tags/releases. I don't think I do at the moment, you'll have to check my permissions.

[CEXT-Dan]

You should be able to create and edit releases for the repository, the permissions are default.
I don’t think the PyPi workflow will fire though, I think I’d have to add you as a collaborator on PyPi, do you have a PyPi account?

That is if your interested, or feel you would have the need to publish independently from the C++ side

[gswifort]

Okay, I can add releases. I don't have a PyPI account. Maybe when the next release is ready, let me know and I'll create it and see if the workflow works.

[gswifort]

onload version is removed, version could be moved to _host_init.py

I don't understand this

[CEXT-Dan]

The version is no longer printed on the command line when loading
Now it only says

Python Interpreter Loaded successfully! :

If we need the version to be printed on the command line as before, it should be done in _host_init.py.
Reasoning, the python side might want to append I.e.

print("Loaded {}.{}".format(DLLVERSION, __VERSION__))

[gswifort]

#409 (comment)

Sorry, I don’t want __init__.py to be set by a different process, I thought I had that clear

Do you mean the version.py file or the setup.py file?

[CEXT-Dan]

You can ignore that since the VERSION_REVISION is removed from the ARX modules.
Need to think about how python only releases are versioned, maybe VERSION_REVISION is good enough for that

edit: maybe something like

1.1.1.1
MAJOR, MINOR, CPPREV, PYREV

[gswifort]

I'm a little lost. What stage are we at? Are you expecting any response from me?

[CEXT-Dan]

_host_init.py now displays the version, so I think we’re good to go.

[CEXT-Dan]

@rdesparbes , I removed you as a collaborator for security. you haven't been around... I will add you again if you find your way back here

[CEXT-Dan]

try to make a release

v2.2.24

pip install cad-pyrx
Added new command PYPIP
Added support for BricsCAD beta 2

[gswifort]

I added this:

PyRx/setup.py

Lines 34 to 36 in d7df64c

	import traceback
	traceback.print_exc()
	revision = "0"

Maybe we should remove it from the workflow and re-release it? The package will build but won't be published (we'll be able to see the logs):

PyRx/.github/workflows/publish.yml

Lines 32 to 33 in d7df64c

	- name: Publish package distributions to PyPI
	uses: pypa/gh-action-pypi-publish@release/v1

[CEXT-Dan]

Maybe we should remove it from the workflow and re-release it?
It’s not clear to me, I know I had to delete the release / recreate releases a few times when I first set it up. IMHO, let the work flows run so we know it works. I can delete the ones we don’t need off PyPi later

[gswifort]

ok, so I'll try to fix it

[gswifort]

Success! Please remove the invalid release.

[CEXT-Dan]

works! yay!

Installing collected packages: cad-pyrx
Successfully installed cad-pyrx-2.2.24.4651
PS D:\pyrx_embedded.bundle\Contents>

[CEXT-Dan]

Does not work for me, I would like to roll back these changes to
SHA-1: 0f5cbc1

[gswifort]

what's not working?

[CEXT-Dan]

Last release came out as cad-pyrx 2.2.25 on pypi
I rolled it back again. I was just was not happy with some parts of the package being versioned by a workflow and others not.

I think we can look at this again at some later date