unique versions

[gswifort]

now the situation is that if I have cad-pyrx version 2.2.6 installed and I want to install from the latest commit python -m pip install -U git+https://github.com/CEXT-Dan/PyRx.git the installation is skipped because pip detects that the package version is the same as the installed one. The solution is to use setuptool-scm, which automatically assigns a unique version number to each commit. For example, if the current version is 2.2.6, the first commit after the commit tagged v2.2.6 will have version 2.2.7.dev0, the next 2.2.7.dev1 etc. This will not affect the releases in any way.
Do you think this is a good idea?

[rdesparbes]

It's always a good idea to make version numbers unambiguous.
But for your immediate problem, you can still use the --force-reinstall flag, no?

[gswifort]

Yes, but I would like to avoid confusing other users who are less familiar with python and pip.
(In my case it's usually best to use --no-deps too).

[rdesparbes]

Users that are willing to pip install directly from git to get the latest (potentially unstable) version are more likely advanced users that would not be afraid by additional flags in this already quite big command IMHO 😁

[gswifort]

Regarding stability.. I am not sure if the right level was chosen for PyPI

I think 4 would be more appropriate.

[CEXT-Dan]

I don’t think it’s beta, but not mature either

[gswifort]

I just wonder if the problem will be that the version will be changed automatically only for python. ARX will still have one version until the next release.

[CEXT-Dan]

right, currently, it’s also compiled in

.DLL version, if you right click on the DLL, you get the version
Though, I might have missed setting the .DLL version on the last release to PyPi

It also matches the Setup.msi for AutoCAD and PackageContents.xml

Command PYRXVER prints the actual build version
PyRx version <2.2.006.20250824> loaded:

All versioning should match

[CEXT-Dan]

that 08 looks wrong 😨

[CEXT-Dan]

I had thought about setting the next version immediately after a release. But that won’t help versioning with refresh builds

[CEXT-Dan]

that 08 looks wrong 😨

fixed

[gswifort]

All versioning should match

I'm not convinced that all version numbers should be exactly the same. For releases, yes, but intermediate commits may differ, I guess.

[CEXT-Dan]

I think it would be okay to append YYYYMMDD I.e. 2.2.6.20250424
It would match Ap.Application.pyrxVersion() (close enough)
it should be in the form of a script that could change __version__ = "2.2.6" to __version__ = "2.2.6.20250424"
I can then add a post build event in visual studio.

edit maybe version should be __version__ = "2.2.006.20250424" to exactly match

[CEXT-Dan]

just to clarify, I would modify the "2.2.006" part each release, so the script would just need to append

[CEXT-Dan]

Another option is to use GitWCRev , I.e.

GitWCRev $WCREV=7$ would evaluate to something like 2.2.006.c16403b

[gswifort]

That would probably be best. I'll check if I can achieve the same via setuptools-scm (I think so).

[CEXT-Dan]

this needs to change the C++ header files with a prebuild event
Ap.Application.pyrxVersion and the version should match

by appending YYYYMMDD, this would not be necessary

[CEXT-Dan]

I think we shouldn’t do anything yet. I need to stew on this for a while

[CEXT-Dan]

Q, What happens if, there’s a project that has pyrx as a dependency
dependencies = ["cad-pyrx>= 2.2.006.c16403b"]

[gswifort]

You're right, that won't work, pip needs to be able to tell which version is newer. So it's necessary to add suffixes dev0, dev1 etc. The number of commits after the tag can be found in git describe --tags --long (remember to fetch tags from github git fetch --tags)

[CEXT-Dan]

dependencies = ["cad-pyrx>= 2.2.006.20250424"] would work right?

[CEXT-Dan]

I added a new file pyrx_version.h

Now it appends YYYYMMDD
Using the date has server me well over the years as it’s pretty easy to track down stuff

If we don’t like the date, I added a constexpr pyrx_uniqueid
See https://github.com/CEXT-Dan/PyRx/blob/26355cccb7d2c25c88f5f265700b7b5d142b1157/pyrx_version.h#L7C26-L7C40

Whatever script changes the version on the python side should change this value before the modules are compiles.

Visual studio has a pre-build event that can run .BAT files

[CEXT-Dan]

I added $WCLOGCOUNT&65535$ to the binary version which currently evaluates to 4171
Should be the same as git rev-list --count --first-parent main

If you can do the same with setuptool-scm, then the python version and the binary version will match when I commit binaries
Otherwise, I can add $WCLOGCOUNT&65535$ to __init__.py

Ap.Application.pyrxVersion() will valuate to something like 2.2.6.4171.20250425
init.py does not need to have the date

[CEXT-Dan]

the binary version will also match

[gswifort]

Thank you, I'll probably take care of it in a few days.

[CEXT-Dan]

Okay, I added it to my generator, in case I need to make a release beforehand
it may be good enough, or we can improve it later. It only changes when I refresh the binaries. So not for every commit