It tab-completes very great. And even earlier than in your version.
Only if you remember it starts with a 'g', instead of the original 't'.
If you're following official documentation and trying to use 'task'
and wondering why it's red and not found, tab-complete will save you
there.
It will autocomplete to taskwarrior first. That might be greater problem
with UX.
Moreover, before making this package happen I was speaking with original
maintainer via email, and he declines binary renaming "because docs says
it's task". Moreover I agree with Egor - why should we change names to
make a mess in user's brains while reading documentation?
Because the alternative is making the package conflict with `task`, so
one cannot have both installed on the system. That is worse.
The user is free to setup an alias to use 'task' as per the
documentation if they do not also use community/task.
Users will expect "taskfile-git" to behave just like written in docs, so
"task" should be a command for that package. That was original
maintainer's intention.
As I can see, you've just picked up this package and "fixed" it without
even trying to contact me and filed a deletion request for package that
fixes problem in more proper way (using org's name).
The package did not download, was out of date, did not build,
conflicted with [community], had missing completions (still does for
fish/ps to be honest) and had a wrong license.
The proper way to deal with those is not creating yet another AUR
package, the proper way is to fix the existing one, which I have done,
and then noticed you duplicated the package, hence I filed this
deletion request.
So we should expect deletion requests for all these packages, right?
https://aur.archlinux.org/packages?O=0&SeB=nd&K=go-task&outdated=&SB=p&SO=d&PP=50&submit=Go
Again, I'm asking to reconsider and withdraw/deny this request.
https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission
See second rule here, your package at this point is just naming the
binary differently, which is just pointless duplication, let's rather
reach consensus on what it should be named as.
Which CONFORMS second rule, because package on time of submission was up
to date BUT maintainer REFUSES to change resulting binary's name in sake
of UX. Can't blame him for that.
Maybe this entire issue should perhaps be raised upstream as 'task' is
very generic. Taskwarrior started in 2008 and task in 2017. Though I
doubt anything useful would come of it.
https://github.com/go-task/task/issues/697 for homebrew tap, yet same
can be extrapolated on other platforms too. They don't care. They don't
use taskwarrior (apparently), they want to use "task" as binary name for
taskfile. But masking that behind "backward compatibility" shim.
Anyway the options are -
A) go-task
B) task-go
C) keep task and conflict with community/task
D) Something else
Also, take a look at search results I mentioned before - go-task is
already used for versioned version of this package. I would go for that
- create a "go-task-git" package with same description as for "go-task"
package (so AUR helpers would show results for "taskfile" string) and
name binary as "go-task". In that case I would have no objections about
deleting my package.
--
With best regards,
Stanislav Nikitin (also known as pztrn).
Email: pz...@pztrn.name
Telegram: @pztrn
