-
-
Notifications
You must be signed in to change notification settings - Fork 625
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
Consider use as an external library #121
Comments
While task is a great CLI tool, my personal opinion is that the underlying code may not be among the cleanest, and not all packages has the right separation of public vs private members. I should add as a disclaimer that there is some time since I last looked at the code base. Still, I think the best approach for this issue may be to first suggest/dream up a good spec for how a minimal public interface should look like, and then those public functions can either be reimplemented or call code living in packages under the Basically hide away most of the code under |
PS! I think that the code base has changed significantly since my last contribution, so a lot of code does already live in the |
@smyrman Yes, I have been trying to refactor things step-by-step, specially splitting code to packages and declaring interfaces to abstract code I agree that once we declare the use as a lib as "officially supported" we should worry about backwards compatibility @jaxxstorm By now, if you don't want to wait, feel free to open a pull request moving the |
Agree that stabilising the API is a good idea. I think worrying about not breaking people in the future is fools gold. Hey ? It's a tool not an APP delivered over Google play with a server using grpc that needs to support Schema Evolution. Being a tool means yes breaking the API. I just worry that stable API / schema is too much work Then I think about how Mage supports plugins. It allows me to build a version of task that I need for my users. Break my plugins instead is better and let me insulate my users from change. |
@andreynering what's the status and plan to tackle this? I'm interested in using taskfiles as an external library. I'd like to be able to programmatically list and run available tasks. Is there anything I can do to help? |
The This will allow people to run Taskfiles programatically. Consider this to be unstable for now, though. No backward compatibility guaranteed. |
I've try run cmd/task/task.go in different repo for test, Somehow it says does not contain package args and taskfile. @andreynering
|
Hi @chinglinwen, Sorry for the confusion, but this was just released on v3.0.1, which wasn't available when you tried. That should work now. |
It works now, thank you! @andreynering |
@chinglinwen any chance we could get some documentation or an example on how to call task as an external library ? |
Though it's a long time ago to remember this @retr0h you may needs to do some change, supplement all the parameter etc. there is an example: https://github.com/go-task/task/blob/master/cmd/task/task.go#L144 |
I have a use case I'd like to have considered.
I'm building an internal application which will:
Taskfile.yml
instancestask -d <dir>/Taskfile.yml
on all those taskfiles concurrentlyAs pointed out in slack, I can use
os/exec
for this, but ideally I want to be able to just importgithub.com/go-task/task
and then use those functions/methods from there. This will ensure that user's don't need to download a binary to run the internal toolWould this be something that might be considered?
The text was updated successfully, but these errors were encountered: