Use Bespoke Tool Path for dotnet-lambda Commands - #127
Conversation
There are situations in which the user's installation of "Amazon.Lambda.Tools" can be as good as read-only. This installs the builder's copy of the tool to a known location which is separate from the user's default global installation. Resolves: #126
| if tool_dir is None: | ||
| env = None | ||
| else: | ||
| env = SubprocessDotnetCLI._merge( |
There was a problem hiding this comment.
I'm far from a Python expert, so if I've made a hash of this, please do let me know.
There was a problem hiding this comment.
We have dropped support for running Lambda builder in Python 2.
Let's directly use env.copy().update(...) instead.
|
you can use your own custom makefile builder for dotnet runtimes to add additional arguments to the binaries that are being used for building. Here is an example for using makefile for custom runtimes, but a makefile builder can still be used for officially supported lambda runtimes. |
@sriram-mv I’m sure I can, but that doesn’t change how the builder outright fails on Docker images in which Even if this approach isn’t the best one (and it felt like a kludge as I wrote it), that assumption of ownership is too fragile. |
| if tool_dir is None: | ||
| env = None | ||
| else: | ||
| env = SubprocessDotnetCLI._merge( |
There was a problem hiding this comment.
We have dropped support for running Lambda builder in Python 2.
Let's directly use env.copy().update(...) instead.
| LOG.debug("Installing Amazon.Lambda.Tools Global Tool") | ||
| self.subprocess_dotnet.run( | ||
| ['tool', 'install', '-g', 'Amazon.Lambda.Tools'], | ||
| ['tool', 'install', '--tool-path', self.tool_dir, 'Amazon.Lambda.Tools'], |
There was a problem hiding this comment.
This would still be a global tool but with a custom path.
https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools
As a global tool in a custom location (also known as a tool-path tool).
The tool binaries are installed in a location that you specify. You can invoke the tool from the installation directory or by providing the directory with the command name or by adding the directory to the PATH environment variable. One version of a tool is used for all directories on the machine.
Maybe we can use local tools instead and check whether a global Amazon.Lambda.Tools is already installed.
As a local tool (applies to .NET Core SDK 3.0 and later).
The tool binaries are installed in a default directory. You invoke the tool from the installation directory or any of its subdirectories. Different directories can use different versions of the same tool.
We should also check whether a global version of the Amazon.Lambda.Tools is already installed and skip over if needed.
|
Closing due to inactivity. Feel free to reopen the PR if there's any update |
5 participants
There are situations in which the user's installation of
"Amazon.Lambda.Tools" can be as good as read-only. This installs the
builder's copy of the tool to a known location which is separate from
the user's default global installation.
Resolves: #126
Issue #, if available:
#126
Description of changes:
Adds the concept of a "tool directory" to the settings for dotnetcli. It's currently set to the value of the scratch directory. By doing this, the user's installation of "Amazon.Lambda.Tools" can be treated as read-only, whether it actually is or not.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.