Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: new interface for version 1.0 #88

Open
tobixen opened this issue Jan 5, 2022 · 12 comments
Open

RFC: new interface for version 1.0 #88

tobixen opened this issue Jan 5, 2022 · 12 comments

Comments

@tobixen
Copy link
Owner

tobixen commented Jan 5, 2022

I'm in the process of rewriting calendar-cli from scratch.

Design thoughts are available as NEW_CLI.md.

I've also written a shorter and more up-to-date user guide.

I'd be happy to see discussions and feedback here.

See also #87

@fauxmight
Copy link
Contributor

fauxmight commented Jan 8, 2023

kal is already excellent. The direction you are moving is very much appreciated.

As there is a great deal of overlap and potential for confusion, and as you have indicated an intention to continue to maintain calendar_cli for the foreseeable future, it looks reasonable to split kal into its own repository maintaining independent documentation for the two projects.

Also, I'm pretty sure the bike shed should be painted yellow.

EDIT: Should you see fit to split the repositories, I will push PRs for separate documentation on the two. That's a little less work on your shoulders.

@tobixen
Copy link
Owner Author

tobixen commented Jan 8, 2023

Thanks for your input. I think you are right, for many reasons:

  • The package name and the command name should match, otherwise there will be confusions.
  • "kal" is apparently available in the github namespace - no reason not to grab it while it's possible!
  • There is very little code overlapping - somehow I've ended up rewriting almost all the logic.

At the other hand:

  • Unfortunately I'm not equally lucky on pypi - someone already has a competing "Personal assistant cli tool" out there. I haven't looked into it, nor figured out how to get around this problem.
  • There will be quite some work now removing/redirecting all references to calendar-cli from kal and vice versa.
  • The calendar-cli project already has some traction, a new project will probably be more difficult to find.
  • Some code - notably the code for reading configuration files - has been moved out to a common library by now (though, I apparently had forgotten to do a "git add", meaning that the master branch has been broken for a month - I should fix up some automatic testing framework). Now I will have to consider weather to maintain it separately, split it into a separate python package, or what.

@fauxmight
Copy link
Contributor

While I have no advise for the pypi issue, I'll be happy to have a buildable master branch.

I've been doing work (like the template PR) from a working AUR-built 0.14.1 and then adapting it in a git repo cloned from your master.

@tobixen
Copy link
Owner Author

tobixen commented Jan 8, 2023

There is no "github namespace", there are other kal projects out on github.

https://aur.archlinux.org/packages/kal has upstream https://github.com/xyproto/kal

Hence "kal" cannot be used as the project name ... and it's not even good as the command name since it already exists from before.

@tobixen
Copy link
Owner Author

tobixen commented Jan 8, 2023

I think it would be good with a new project and command name ... something unique, but still easy to type and easy to remember. Came to think that quite some commands nowadays are suffixed with "ctl" - notably systemd control commands, but also journal. Could calctl be an appropriate name? It's at least available.

I also asked ChatGPR for help. Asking for something unique, easy to type and easy to remember, it suggested:

  • calendar
  • agenda
  • sched
  • organize
  • planner
  • appoint
  • event
  • schedule
  • clock
  • time

Complaining that those lacked uniqueness, it came up with this:

  • chrono
  • calcmd
  • agendio
  • schedio
  • organizio
  • plannerio
  • appointio
  • eventio
  • schedulio
  • timio

@tobixen
Copy link
Owner Author

tobixen commented Jan 8, 2023

Came to think, planner may be cut short to plann, and it will be unique, short, easy to remember and easy to type.

@fauxmight
Copy link
Contributor

fauxmight commented Jan 8, 2023

plann sounds reasonable

calcmd is reasonably close to the original project name and may retain some association with the traction acquired by the calendar-cli project.

Other modifications of kal that don't appear on a brief search to have significant projects associated therewith:
xal
xhal
chal
gkal - EDIT: bad choice 'g' implies association with 'gnu'
qal - EDIT: bad choice 'q' implies association with 'qt'
qhal - EDIT: bad choice 'q' implies association with 'qt'

EDIT:
calendcli also appears available but may be confused with several projects called calencli

EDIT2:
caldavcli looks descriptive, close to the original name and available.

EDIT3:
kaldav looks available, too, though there is a github user named 'kaldav.'
'kaldav' is my official vote for proper bike shed color.

@tobixen
Copy link
Owner Author

tobixen commented Jan 8, 2023

I sort of liked qal, didn't think about QT at all - but alas, there exists aqal-package in pypi. As for gkal, my associations goes towards google. There was actually another calendar-cli package which was for Google calendars, the maintainer changed the name to something starting with g to avoid the name conflict.

As for variants over caldav - I don't like it that much, ideally end-users should not have to care what protocol is being used between the cli tool and the calendar server, and it may be that other protocols will be supported in the future. Hence I think the alternatives are plann, calcmd, calctl and calcli.

@tobixen
Copy link
Owner Author

tobixen commented Jan 9, 2023

I think I'll go for plann.

  • It seems to be pretty unique (though I haven't done any deep research into it)
  • It's easier to type and easier to pronounce than calcmd or calctl or even calcli. Not only that it's one character less, but also involves less movements on the keyboard.
  • For me, the word "calendar" may be a physical thing hanging on the wall making it easy to map weekdays and month days. There is one thing I don't have any plans to add to this tool, and that's such an overview of a month (there are tons of other tools that may do that). At the other hand, a list of events and tasks that I'm going to participate in and do, what is that if not a "plan"?
  • "Planning" involves checking up and adding things to the list of events/tasks.
  • plann add event and plann add task sounds like good commands to me.
  • One of my stated goals is to let the tool be "a thin wrapper over existing libraries like the caldav library" - but I also have the slightly conflicting ambition to let this be a full-fledged planning tool. Establishing a python package plann is a good thing to do, extra functionality (like my "panic calculation" feature, checking if it's at all possible to perform everything on the plan) that aren't directly related to cli, caldav nor ics may then be made available through import plann (It seems less nice with import calcli, import calcmd nor import calctl).
  • I think plann is a better name for a full-fledged planning tool than calcli, calcmd or calctl.

@fauxmight
Copy link
Contributor

Huzzah! Long live plann!!
Sounds like a well-reasoned thought process throughout.

I'll submit PRs to modify kal -> plann in docs on both repos soon.

@tobixen
Copy link
Owner Author

tobixen commented Jan 9, 2023

From https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4542940/ ...

Plann: A command-line application for annotating plastome sequences
(...)
Plann is a Perl script to be executed on the command line.

Well ... I'm pretty sure that for any short, memorable, easy-to-type, easy-to-remember command there will be some conflicts. I think I will still go for plann.

tobixen added a commit that referenced this issue Jan 9, 2023
@tobixen
Copy link
Owner Author

tobixen commented Jan 9, 2023

And the version number for calendar-cli should be bumped to 1.0 eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants