Created attachment 249573 [details] New port: Simple command-line CalDav client This is my first attempt at submitting a port to FreeBSD, so please correct me as appropriate. I did post a link to this commit on #freebsd-python a week or two ago, which hopefully ironed out the worst mistakes. To the best of my knowledge, this calendar-cli is the most usable command line tool around for querying CalDAV servers. At least it is the only one I've found which is useful to me. I've been relying on it daily for a few years and contributed a few minor patches. I think it deserves to be easily discoverable for everyone and installable without needing to dance around with venv and pip. According to https://wiki.freebsd.org/Python/PortsPolicy#PKGNAMEPREFIX > Ports MUST use PKGNAMEPREFIX, unless there is a compelling case not to. This tool being an end-user application is hopefully a compelling reason to skip the prefix. A typical user couldn't care less what its implementation language is, or which version of python that.
Created attachment 254448 [details] New port: Simple command-line CalDav client Rebased to current main. Mainly due to the python 3.9→3.11 transition causing my locally installed package to disappear. The version of the patch also updates the py-yaml → py-pyyaml renamed dependency. I would find it lovely if this could make in into ports, but I guess most FreeBSD maintainers use Outlook Web Access or Google Calendar and can't see the point of a CalDAV cli tool? ;) Please help me understand what would be needed to get this to a mergable state.
Created attachment 257544 [details] Third time's a charm? Patch rebased and modified. After having used python applications under FreeBSD for a year or so I've finally understood that there are technical reasons for setting PKGNAMEPREFIX, even for end user targeting stuff. Thus the variable now gets set, and the comment on compelling reason has been removed. Do we believe there might be any chance that this could get merged?
The README of this software says "THIS IS THE LEGACY VERSION" and directs to https://github.com/tobixen/plann cos, do you think this port should be abandoned or committed nevertheless?
TL;DR: Yes I think this software is still the relevant one to package, because it is the version which actually works. That same section of the README also contains this sentence: > If you need a production-ready mature command-line utility for accessing your calendar, then this is the right tool ... as for now. While the author has moved on to use plann instead, he has also publicly communicated the intent to continue maintaining calendar_cli, and accepts quality related PR:s (as stated in the same README). As always, the devil is in the details. In its current state plann is too buggy to be used for many use cases. I have attempted to migrate. Unlike calendar_cli, plann confuses different calendars. Depending (likely) on the server implementation, queries return all events for every calendar (including a completely different user's shared ones) regardless of filtering. CalDAV is a complex protocol, for which libraries, clients and servers tend to take quite a while to mature. Ideally one should debug and fix the new tool, but for now calendar_cli is the tool best suited for distribution through ports to users not necessarily prepared to themselves dig into the code straight away.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1c8c01d00c41de726a1a545bfec9b1f31ed12d02 commit 1c8c01d00c41de726a1a545bfec9b1f31ed12d02 Author: cos <freebsd.org@fydagy.netizen.se> AuthorDate: 2025-03-02 10:18:23 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2025-03-02 10:19:06 +0000 deskutils/py-calendar_cli: Simple command-line CalDav client PR: 278045 deskutils/Makefile | 1 + deskutils/py-calendar_cli/Makefile (new) | 26 ++++++++++++++++++++++++++ deskutils/py-calendar_cli/distinfo (new) | 3 +++ deskutils/py-calendar_cli/pkg-descr (new) | 4 ++++ 4 files changed, 34 insertions(+)
Pushed.