Future plans

[stefan6419846]

I just stumbled upon your repository which seems to be the only fork with issues enabled.

What are your plans for the future of this fork? I have seen #1 and your commits, but the last real activity seems to have happened in February, only changing smaller stuff. I assume that Travis is not running as well due to Travis changes and no existing GitHub Actions configuration? Additionally, is the version parsing actually required?

I am asking as python-xmp-toolkit is used in quite some projects and while searching for an alternative, a version with some actual further maintenance which can be relied upon is appreciated.

[zougloub]

Hi @stefan6419846 (I need to work on my handling of notifications...).

I am just planning to be reactive (great start, I know...) as issues are raised. Since (#1) we may be able to get access to the original upstream location, I encourage you to open issues there if you have any.

[stefan6419846]

You are not receiving any notifications by default as forking a repository will not watch it automatically, thus it is easy to miss notifications in such cases, especially when enabling the issues section.

I do not have any actual issues yet, as the most problematic issue is only present starting with Python 3.12 and it dropping distutils, while my default interpreter stil is not Python 3.12. Nevertheless, the main point of opening this issue is about how serious any attempts on your side really are, with #1 not really moving forward as well. This especially holds true if I want to use python-xmp-toolkit in some bigger project, where at least some active maintenance makes sense to avoid flogging a dead horse.

Coming back to my initial comment:

• I consider automated tests and continuous integration, nowadays usually through GitHub Actions, a hint about the general interest in the quality of the code. For now, there only is a Travis configuration file, but it does not seem to be running on this repository (https://app.travis-ci.com/exmakhina/python-xmp-toolkit) and uses quite some outdated constructs like setup.py test and only covering Python 2.6, Python 2.7 and Python 3.3.
• Do we actually need to parse the value into libxmp.version.VERSION_TUPLE? The packaging requirement could easily be dropped by just defining VERSION_TUPLE and automatically joining the actual VERSION from it instead for example.

[zougloub]

• sent another e-mail to Lars, the upstream maintainer
• de-travised the repo (instead using github actions);
• added python3.12 testing;
• removed packaging dep;

In the future please use one issue per topic, so they're easier to track. Merge requests are welcome.

[stefan6419846]

Due to being my first impressions, I aggregated my first observations in this ticket. I usually open dedicated issues, but in this case I did not see any real value unless the current status is clear.