Suggestions about release cycle about whitebox-python

[giswqs]

The Python binding is noarch, meaning it is not os specific. User only will download the OS specific WBT binary during initialization rather than installation. It would be overwhelming to include all five binararies >100MB in the PyPI package. whitebox is being using by many other packages. We want the installation to be smooth and fast. I would prefer to pull the WBT binaries from a central location rather than including them in the PyPI package.

[giswqs]

Yes, ideally, we want the pypi package version to the same as the WBT backend. I usually made a few patch releases (e.g., v2.3.1, v.2.3.2, v2.3.3) before make the minor release (e.g., v2.4.0). If we sync the pypi package version the WBT backend right away, then the pypi version will be newer than the WBT backend when we fix bugs and release a new version.

And yes, it would be great to host versioned binaries on the Whitebox server so that users can roll back to an earlier version of WBT binary. It is up to @jblindsay's decison. We discussed this issue previously at giswqs/whitebox-bin#1

[sg-novelt]

Thanks a lot for the rapid answer!

If we sync the pypi package version the WBT backend right away, then the pypi version will be newer than the WBT backend when we fix bugs and release a new version.

I get that. Would it be feasible to adopt a versioning schema along the lines of v2.4.0-1, v2.4.0-2, etc., to make it extra clear that these are the bindings to be used with v2.4.0 of WBT back-end, with the rightmost digit being used for patches made internally to the Python bindings?

And yes, it would be great to host versioned binaries on the Whitebox server so that users can roll back to an earlier version of WBT binary. It is up to @jblindsay's decison. We discussed this issue previously at giswqs/whitebox-bin#1

Thanks for linking to that past discussion. I think it would definitely be useful to host these versioned binaries somewhere. I don't know what the current limitations are (legal, ownership, technical, other?), but it's a real bummer not to have access to it. We are working around this by compiling ourselves from the sources which are tagged with proper version numbers on GitHub. However, if that's something the Python bindings do not plan to do themselves, it would be a big downside for users in our opinion.

Let's wait for @jblindsay's opinion on this matter. Again, we'd like to offer our help if you think it would be relevant.

[giswqs]

Good suggestion. I can generate new version following {major}.{minor}.{patch}-{pre_l}{pre_n}. I use bump-my-version to bump versio.

I do keep a copy of previous WBT releases on my own, but I did not include them python bindings. I would prefer the versioned binaries to be hosted centrally on whiteboxgeo.com or the WBT GitHub repo if it is something @jblindsay willing to do.

[sg-novelt]

Good suggestion. I can generate new version following {major}.{minor}.{patch}-{pre_l}{pre_n}.

That'd be perfect 👌.

I do keep a copy of previous WBT releases on my own, but I did not include them python bindings. I would prefer the versioned binaries to be hosted centrally on whiteboxgeo.com or the WBT GitHub repo if it is something @jblindsay willing to do.

Yes, @jblindsay's opinion will definitely be needed here.

Any reason why you discard the possibility to compile the WBT back-end within the Python bindings, and ship the resulting binaries in the package that gets uploaded to PyPI? I think this is what would give the most control/safety over what's getting packaged in the bindings (although, arguably, this is not the easiest option to implement).

[jblindsay]

Just noting that previous binaries are available on PyPi for Whitebox Workflows.