-
Notifications
You must be signed in to change notification settings - Fork 64
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
Management of locally installed dotnet tools #44
Comments
@AgentEnder I can start working on this today. The steps you've laid out are enough to get me started. |
@bcallaghan-et Make sure to extract the steps for checking if tool is in manifest + checking if tools have been restored to utilities so they are easy to use from other generators. |
When a tool is installed locally, the binaries are cached in a global location, and the version number is noted in the local manifest file. If the same tool is re-installed, the cached binaries are used. Would it be acceptable to "install" the tool every time, rather than checking if it has been installed? |
As long as the cached binary is used instead of deleting and reinstalling I am good with that. |
Create the manifest file so future generators can install local tools Fixes #44
Add a method that future builders can use to install additional tools Fixes #44
Add restore to prepare script so new installs fully set up the workspace Fixes #44
# [0.6.0](v0.5.2...v0.6.0) (2021-05-19) ### Bug Fixes * **core:** add unused options parameter ([c434d32](c434d32)) * **core:** pass client through to init schematic ([5908947](5908947)) ### Features * **core:** add a generator for dotnet restore ([96082a1](96082a1)) * **core:** add restore to prepare script during init ([c2b1c23](c2b1c23)), closes [#44](#44) * **core:** create tool manifest during init ([996aaee](996aaee)), closes [#44](#44) * **dotnet:** add a method to install local tools ([6ab5d4a](6ab5d4a)), closes [#44](#44)
🎉 This issue has been resolved in version 0.6.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I definitely agree about installing tools being the path for getting this executor up and running.
I see something like this:
nx format my-api
-> Executor checks for tool in manifest, installs if missing -> Executor checks that tool has been restored, reports error message otherwise -> Executor runs tooldotnet restore
anddotnet tool restore
)nx g @nx-dotnet/core:restore
to npm prepare scripts. Something like:I'll create new issues for the tool management when I am home this evening.
After we get tool-mgmt in, this executor should be pretty quick to test.
Originally posted by @AgentEnder in #13 (comment)
The text was updated successfully, but these errors were encountered: