Closed shelllee closed 7 months ago
hello @shelllee - i though about this a bit more.
the mission of this extension is not to "replace" the rustup / cargo toolchain ecosystems but to bring the power of VS into Rust development. specifically the editor, debugger & testing experience and then enhance them with rust community best practices (e.g. fmt, clippy etc.)
my thinking at this point is adding a template does not align with that mission. it can easily be done by opening a command prompt and firing cago new
which will then immediately show up in the solution explore.
therefore i am thinking of resolving this issue as 'wont fix'. let me know what you think.
hello @shelllee - i though about this a bit more.
the mission of this extension is not to "replace" the rustup / cargo toolchain ecosystems but to bring the power of VS into Rust development. specifically the editor, debugger & testing experience and then enhance them with rust community best practices (e.g. fmt, clippy etc.)
my thinking at this point is adding a template does not align with that mission. it can easily be done by opening a command prompt and firing
cago new
which will then immediately show up in the solution explore.therefore i am thinking of resolving this issue as 'wont fix'. let me know what you think.
I'm sorry for replying so late to you.
Firstly, your description of the plugin mission is "not to replace..." is reasonable, but I don't think creating a Rust project through a template is considered as a replacement, unless there is something I am not aware of, such as the underlying implementation of the template is not cargo new
, but rather copy
. If the latter is the case and VS only provides the later, then the former might be a better option. However, if the result of cargo new
is stable and doesn't change much, I think there is not much difference between cargo new
and copy
. As someone who is new to Rust and not familiar with many of its aspects, I'm just sharing my thoughts, which might be wrong.
Secondly, the need to create a Rust project in one step through VS is reasonable (rather than two steps: locating the cargo new file and then opening the folder through VS). For example, VS integrates with CMake in two ways: one is to create a CMake project and automatically initialize the CMakeLists.txt file, and the other is to locate the folder through VS (more suitable for existing projects, such as those pulled from GitHub). This makes VS a convenient tool for many people and improves its ecosystem. I raised this need probably because I am a heavy Windows UI user and a bit lazy, and perhaps other people also have this need. Of course, this need can also be fulfilled by other plugins or methods.
Now, I suddenly thought of a new way:
cd somedir
cargo new project_name
devenv project_name
But there are two issues:
devenv
to the PATH
environment variable.current directory
?Lastly, let's have a philosophical discussion. If your goal is to introduce some useful features from VS into the Rust ecosystem, from the several feature requests that have been created, it seems more like introducing Rust into VS, isn't it?
your 3 points are fair - in essence can only make things better if adding functionality that is aligned with VS way of doing things.
right now though my focus is on getting the fmt/clippy + testing experiences working. once that is done i'll be able to look into this.
would you like to help me out if you have some free time?
sorry for so late again
There is a way to not configuring the path environment variable
@shelllee not sure i follow your question. best to have conversations on the project channel https://discord.gg/JyK55EsACr
closing due to lack of response.
feature request: