Could you please put CommandLineArguments into user-specific configuration file. #7373
Replies: 3 comments
-
Suggestion: Two-tier configuration of CommandLineArguments is welcome and is the most flexible design in my opinion. It means, PTVS still recognize team-wide CommandLineArguments in foo.pyproj(as suggested running arguments for all/most team members), and a team member can override this setting in his own foo.pyproj.user. This requires configuration UI to be updated as well. The UI should tell the user, whether the currently displayed "Script Argument" is from foo.pyproj or from foo.pyproj.user, and make it clear that the changes here will be saved to foo.pyproj.user . |
Beta Was this translation helpful? Give feedback.
-
We need to investigate how C# and C++ projects handle this and probably do the same. |
Beta Was this translation helpful? Give feedback.
-
This feature was also requested in the PTVS survey. |
Beta Was this translation helpful? Give feedback.
-
For a foo.pyproj project created in VS2015~VS2022(up until today, 2022.06.05), if user sets script argument, the argument is saved in foo.pyproj itself .
foo.pyproj will be injected with XML tag:
<CommandLineArguments>param1 "param two"</CommandLineArguments>
I have to say, that is very unfriendly for a team. Team member Tom and team member Bob probably run/test the python program with different arguments, and their settings should not stomp on each other. Therefore,
<CommandLineArguments>
should be placed into another file called foo.pyproj.user . The team will have foo.pyproj checked into git, but not for foo.pyproj.user.Microsoft Visual Studio projects for C++ and C# has a very long history of putting program startup parameters in foo.vcxproj.user and foo.csproj.user, and I appreciate that decision. I've been so surprised that PTVS developers have not realized this better(or best) practice yet.
Hope to see it implemented soon.
Beta Was this translation helpful? Give feedback.
All reactions