XPost: linux.debian.bugs.dist
On Wed, Dec 9, 2020 at 3:21 AM Ansgar <
ansgar@debian.org> wrote:
Given topydo just provides/conflicts with devtodo to provide the "todo" binary, this seems to violate Policy 10.1 "Binaries" unless they provide
the same functionality.
Note that there is a Conflicts because the current devtodo
does not support alternatives.
As I've said elsewhere, I claim they do provide the same functionality, and
are
not in violation of 10.1. I say "topydo and devtodo provide the same functionality - the ability to add, delete, modify, and display discrete tasking information". That is not a false statement. The question is, does
it reflect the intent of the Policy?
From where I stand, I would expect the Policy to use a different word to indicate something along the lines of greater API compatibility. I have no additional background information, though. Are you aware of any expansions
on this text, or of any precedents that could help with a consensus process?
Different "todo" managers should be coinstallable as different users
might want to use different ones.
The scheme I propose allows that.
From the messages I thought todo.txt is a standard *text* format, but
now you say it is a standard command-line interface? What can they do
if they depend on todo.txt?
Todo.txt is an ecosystem of tools built around a file format. There is a canonical
CLI implementation. Topydo was built as an alternative to that. I'm sorry,
but I'm
not sure I understand your question beyond that.
For the most part, todo.txt is an end user tool. As for a theoretical
package
that depends on todo.txt, I believe that the core capabilities it requires
of
todo.txt are:
- a mechanism for discovering the location of the active tasking file
- an optional mechanism for adding pre and post processing hooks to
task modification activities
These capabilities are present in topydo, with the help of todo.txt-base.
This seems to imply I can manage tasks from the command-line like "todo new-task eat breakfast"? What interface to do so is provided? Can I
call "todo <file>", "todo", "todo new-task <task>", ...?
It depends. Topydo can run one-off commands (arg[1] is the command, with a default of "ls" - the same as devtodo). It also has an interpreter mode and
a
GUI mode, which I do not believe are pertinent to the discussion.. Devtodo
has one-off commands as well, along with other end point to support specific commands.
Should emacs provide a "todo" script to open ~/TODO (with say org-mode)?
Again, not sure I understand. To be sure, emacs could be used to edit the
file,
if it knows where it is. Note that part of the virtual packages work-up involves
automatic discovery of the file location across providers (see
todo.txt-base -
https://manpages.debian.org/unstable/todo.txt-base/index.html).
I'm adding a common "--info" argument to all todo.txt providers. An emacs
todo script could use that to identify a todo file to open. But, the core
"todo{.txt}" command does not open the file for editing. See the vitodo
and edittodo commands in todo.txt-base for something similar to what
you are talking about.
All of this is in preparation for another layer of capabilities for todo.txt providers which is not submitted yet.
If your theoretical emacs script met the criterion I listed above ("--info"
and hooks), I'd say it is worth discussing if that could be a
todo.txt provider.
It appears that a virtual package, or at least these virtual packages in particular,
need a distinct spec separate from their implementations. Where would
you expect to find that documentation? Should that spec be part of this
list application process?
If it is just to have "todo" open a user-chosen program they like to
manage their todo lists with, why not just have the user add a "todo"
alias to their shell or $HOME/bin?
This standardizes that process. Part of the challenge with these tool sets
is the variety of things you have to do to get them to a common working
level. My goal in packaging them is to simplify that as much as
possible
- name: todo.txt
description: task management based on a standard free-form text
format
This description seem to vague to me: it doesn't even mention what file format. Does a package providing todo.txt provide any specific user interface? Emacs can edit todo.txt files: would it qualify (even
without a "todo" executable in $PATH)?
Ansgar
Ok ... does anyone have guidance on the line length limit in that yaml file? Could you take a stab at a replacement?
BTW -
https://salsa.debian.org/debian/todotxt-cli/-/merge_requests/2
I'll just say here that your stance feels unnecessarily aggressive from the viewpoint of my inbox. I'm just trying to add value here.
--
AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 3:21 AM Ansgar <<a href="mailto:
ansgar@debian.org">
ansgar@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Given topydo just provides/conflicts with devtodo to provide the "todo"<br>
binary, this seems to violate Policy 10.1 "Binaries" unless they provide<br>
the same functionality.<br></blockquote><div><br></div><div>Note that there is a Conflicts because the current devtodo</div><div>does not support alternatives.</div><div><br></div><div></div><div>As I've said elsewhere, I claim they do provide the
same functionality, and are</div><div>not in violation of 10.1. I say "topydo and devtodo provide the same</div><div>functionality - the ability to add, delete, modify, and display discrete</div><div>tasking information". That is not a false
statement. The question is, does</div><div>it reflect the intent of the Policy?</div><div><br></div><div>From where I stand, I would expect the Policy to use a different word to</div><div>indicate something along the lines of greater API compatibility. I
have no</div><div>additional background information, though. Are you aware of any expansions</div><div>on this text, or of any precedents that could help with a consensus process?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Different "todo" managers should be coinstallable as different users<br>
might want to use different ones.<br></blockquote><div><br></div><div>The scheme I propose allows that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From the
messages I thought todo.txt is a standard *text* format, but<br>
now you say it is a standard command-line interface? What can they do<br>
if they depend on todo.txt?<br></blockquote><div><br></div><div>Todo.txt is an ecosystem of tools built around a file format. There is a canonical</div><div>CLI implementation. Topydo was built as an alternative to that. I'm sorry, but I'm</div><
not sure I understand your question beyond that.</div><div><br></div><div>For the most part, todo.txt is an end user tool. As for a theoretical package</div><div>that depends on todo.txt, I believe that the core capabilities it requires of</div><div>
todo.txt are:</div><div> - a mechanism for discovering the location of the active tasking file</div><div> - an optional mechanism for adding pre and post processing hooks to</div><div> task modification activities</div><div><br></div><div>These
capabilities are present in topydo, with the help of todo.txt-base.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This seems to imply I can manage tasks from
the command-line like "todo<br>
new-task eat breakfast"? What interface to do so is provided? Can I<br>
call "todo <file>", "todo", "todo new-task <task>", ...?<br></blockquote><div><br></div><div>It depends. Topydo can run one-off commands (arg[1] is the command, with a</div><div>default of "ls" - the
same as devtodo). It also has an interpreter mode and a</div><div>GUI mode, which I do not believe are pertinent to the discussion.. Devtodo</div><div>has one-off commands as well, along with other end point to support specific</div><div>commands.</div><
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Should emacs provide a "todo" script to open ~/TODO (with say org-mode)?<br></blockquote><div><br></div><div>
Again, not sure I understand. To be sure, emacs could be used to edit the file,</div><div>if it knows where it is. Note that part of the virtual packages work-up involves</div><div>automatic discovery of the file location across providers (see todo.txt-
base -</div><div><a href="
https://manpages.debian.org/unstable/todo.txt-base/index.html">https://manpages.debian.org/unstable/todo.txt-base/index.html</a>).</div><div><br></div><div>I'm adding a common "--info" argument to all todo.txt
providers. An emacs</div><div>todo script could use that to identify a todo file to open. But, the core</div><div> "todo{.txt}" command does not open the file for editing. See the vitodo</div><div>and edittodo commands in todo.txt-base for
something similar to what</div><div>you are talking about.</div><div><br></div><div><div>All of this is in preparation for another layer of capabilities for todo.txt</div><div>providers which is not submitted yet.</div><div><br></div></div><div>If your
theoretical emacs script met the criterion I listed above ("--info"</div><div>and hooks), I'd say it is worth discussing if that could be a</div><div>todo.txt provider.</div><div><br></div><div>It appears that a virtual package, or at least
these virtual packages in particular,</div><div>need a distinct spec separate from their implementations. Where would</div><div>you expect to find that documentation? Should that spec be part of this</div><div>list application process?</div><div> </div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If it is just to have "todo" open a user-chosen program they like to<br>
manage their todo lists with, why not just have the user add a "todo"<br>
alias to their shell or $HOME/bin?<br></blockquote><div><br></div><div>This standardizes that process. Part of the challenge with these tool sets</div><div>is the variety of things you have to do to get them to a common working</div><div>level. My goal
in packaging them is to simplify that as much as</div><div>possible</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> - name: todo.txt<br>
> description: task management based on a standard free-form text format<br>
This description seem to vague to me: it doesn't even mention what file<br> format. Does a package providing todo.txt provide any specific user<br> interface? Emacs can edit todo.txt files: would it qualify (even<br>
without a "todo" executable in $PATH)?<br>
Ansgar<br></blockquote><div><br></div><div>Ok ... does anyone have guidance on the line length limit in that yaml file?</div><div>Could you take a stab at a replacement?</div><div><br></div><div>BTW - <a href="
https://salsa.debian.org/debian/todotxt-cli/
-/merge_requests/2">
https://salsa.debian.org/debian/todotxt-cli/-/merge_requests/2</a></div><div><br></div><div>I'll just say here that your stance feels unnecessarily aggressive from the<br></div><div>viewpoint of my inbox. I'm just trying to
add value here. </div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE</div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)