Release planning

[sde1000]

Hi everyone!

You may have noticed that there are several new pull requests from @markus-becker-tridonic-com in the queue. I've had a look at them, and I am planning to merge them after I've tested them as well as I'm able to.

I'm going to take this opportunity to make some other changes that I have been thinking about for some time. I've never been happy with the drivers being in the library — we don't have an API that works for everyone, for example — and I've considered moving them to examples/ in the past. (See #69 and #149.)

I'm not going to do that. Instead I plan to split the project in two, creating a new project for drivers and leaving python-dali as a "sans-io" style interface to DALI.

I think this has at least the following benefits:

• python-dali becomes easier to test and maintain. It's there to implement and document the standards, and nothing else.
• It's made clearer that the drivers are not an "official" part of python-dali, and that if they don't work for you (you prefer threaded over asyncio, for example, or want the API to be different, or want to run on an OS with different ways of accessing hardware) then you can just write or find other drivers

Proposed plan

I suspect that many people who depend on python-dali have pinned major version '0'. So to avoid breaking things for them:

1. I plan to merge Add GitHub Actions workflow to publish to PyPI on tag #154 and use it to make a release 0.12 containing the current state of the project.
2. I'll merge the remaining pull requests except Typed #160 and make a release 0.13. (Typed #160 is a bit more global than all the other pull requests.)
3. I'll merge Typed #160 and then split the project. I'll remove drivers from python-dali and make a release 1.0, and in the new "drivers" project I'll replace the python-dali code with a dependency on python-dali, and make an initial release.

I hope I'll get a chance to do this in the next week or so. But before I do, are there any comments?

[markus-becker-tridonic-com]

Plan looks good to me. I'd appreciate a 0.14 with #160 in. Let me know if you need any PR adapted.

[sde1000]

My current plan is to take the day off work and do this on Friday.

[markus-becker-tridonic-com]

My current plan is to take the day off work and do this on Friday.

Very much appreciated!

[sde1000]

Release 0.12 has been published via Trusted Publishing. There doesn't appear to be any direct indication on PyPI that this method was used, though!

[markus-becker-tridonic-com]

See https://pypi.org/project/python-dali/#python_dali-0.12.tar.gz :

[sde1000]

Aha!

[markus-becker-tridonic-com]

Reachable via https://pypi.org/project/python-dali/0.12/#files

[sde1000]

Release 0.13 published. I wasn't able to include the driver run_sequence() and send() merge because that merge request built on top of the "Typed" merge request and would have complicated the history a lot. Rebase it on master if you want me to merge it first; otherwise I'll get to it after the "Typed" pull request.

[markus-becker-tridonic-com]

Pushed #160 as well, but did not have time to check.

[markus-becker-tridonic-com]

Would it be possible to release a version without typing first? Then I could start filing PRs in the depending project.

[sde1000]

I can release current master as a new version now, if that would work?

[markus-becker-tridonic-com]

Yes, it would. Also I am currently letting Claude do further typing.

[sde1000]

Ok, release 0.14 has been pushed to PyPI.

The work I did on typing dali/gear/ and dali/devices/ was interesting. It's revealed some pain points in the public API: primarily, dali.command.Response.value is difficult to use correctly in its current form, which is why many callers (sequences, etc.) use raw_value instead. I will probably open a discussion about this: for the 1.0 release that includes typing I will probably add a deprecation warning to dali.command.Response.value and suggest the use of typed alternatives instead (eg. dali.command.NumericResponse.as_integer)

The current pain point in adding typing to dali/memory/ is that MemoryValue.locations is supposed to be an Iterable[MemoryLocation] (and always will be, because the metaclass _RegisterMemoryValue forces it to be) but is also allowed to be a plain MemoryLocation because that's the common case.

As I work through dali/memory/location.py I'll see how much trouble that causes in practice. Hopefully by the end of the week, if I can get another day to work on it.

[markus-becker-tridonic-com]

HomeAssistant bot complains in home-assistant/core#187347 about the license of python-dali.

It seems PyPI shows "LGPL-3.0-or-later" with quotation marks. Others are showing the license without, e.g. https://pypi.org/project/ecoledirecte/ and https://pypi.org/project/pyvlx/. Would you be able to modify that?

[sde1000]

Fixed, and a new release published.

[markus-becker-tridonic-com]

HA's bot would require #165 to be merged and released.

[markus-becker-tridonic-com]

If you want to try out the integration: https://github.com/tridonic-com/hacs-dali. Not yet on 0.16, though.

The first PR is open: home-assistant/core#187347