Resolve relative paths provided in README or commandline

[jianghaolu]

When an argument is provided on README or AutoRest commandline and the argument points to a relative path, the user is assuming the path is relative to the README file or where the user is running the AutoRest CLI.

getStringValue("output-folder") ===> "..\"
getValue(List.class, "input-file") ===> ["../../../autorest.testserver/swagger/body-complex.json"]
getStringValue("customization-jar-path") ===> "target/bodycomplex-customization-1.0.0-beta.1.jar"

We need a way for AutoRest plugins to get the absolute paths for these arguments.

Solution 1: Repurpose the base-folder configuration, or add a new configuration

Currently, there's a configuration base-folder that always has value ".". We may be able to repurpose this to contain the folder where README.md file is located, or where AutoRest is launched from. Then the plugins will be able to assemble the absolute paths themselves.

**Caveat"": If the user provides some paths on the README and some on the command, then there's no way to tell which base folder is intended by the user for each path argument.

Solution 2: Resolve all the relative paths to absolute paths

We can introduce the absolute version of each path argument, input-file-absolute, output-folder-absolute, and customization-jar-path-absolute, etc. That way the plugins can pick these up directly, and not have to resolve the relative paths.

Caveat: For plugins that do not need the absolute paths for these, there may be a performance hit to resolve all the path arguments.

[lmazuel]

Summary

Today, all the relative paths inside a Readme are solved relatively to that Readme place.

For instance autorest ./a/b/c/readme.md that contains input-file: ../foo.json, will look into ./a/b/foo.json

This applies to input-file and output-folder (@daviwil are you aware or another path autorest.core arguments?)

Problem for people like @pakrym , if "output-folder" is the project folder, then he cannot use clear-output-folder. I have actually have the same problem in Python, and hack that problem with a "no-namespace-folder" and play with paths. It would be valuable for both of us, to make a difference between: this is "the folder of the project I work on" and "this is the folder I want to generate files, and I want autorest to clean for me". @jianghaolu , it seems to me your problem is close: you want to generate in "src" while reading a file in the sibling folder "target".

Solutions I have in mind:

Solution 1:

output-folder stays the project folder, but we add a clean-folder that can clean a relative sub-folder

Example of conf:

output-folder:$(sdk-root)
clean-folder:./src
customization-jar:./target/bodycomplex-customization-1.0.0-beta.1.jar

Problem is that we need now to prefix all "WriteFile" call with "src". So not sure I like it.

Solution 2:

Add project-folder, and output-folder stays the generation folder

Example of conf:

project-folder:$(sdk-root)
output-folder:./$(project-folder)/src
clean-output-folder: true
customization-jar:./$(project-folder)/target/bodycomplex-customization-1.0.0-beta.1.jar

This last one is more a convention and don't deserve extra code from David. I believe autorest already support recursive variable injection like that. This is the less disruptive, and we can tight the customizations to the presence of a project-folder. I can imagine myself simplifying a ton Python as well, and deprecating no-namespace-folder too.

Thoughts?

[iscai-msft]

Thanks @lmazuel I definitely prefer the second one, it keeps the basics similar, but allows users greater customizability (idk if that's a word)

[ShivangiReja]

@lmazuel I really like the second option and it would work well with c#. Thanks for suggestion.

[lmazuel]

@timotheeguerin please write some doc and close it