robotcode icon indicating copy to clipboard operation
robotcode copied to clipboard

[QUESTION] Support Alternate Robotidy/Robocop Configuration File Name

Open martinezlc99 opened this issue 1 year ago • 5 comments

Please describe. I understand robotcode will use the closest pyproject.toml file to find the robotidy configuration. However, I prefer the .robotidy configuration file name, which is also supported by robotidy.

Similarly, robocop will use the closest .robocop first, but will also accept a pyproject.toml as well, although it doesn't seem like robotcode doesn't support reading from a configurations file.

Can this alternate file name be configured?

Desktop (please complete the following information):

  • VS Code Version 1.94.2 (Universal)
  • RobotCode Version 0.93.1
  • OS: macOS
  • Python Version 3.12.7
  • RobotFramework Version 7.1.1
  • Robocop 5.4.0
  • Robotidy 4.14.0

martinezlc99 avatar Oct 27 '24 05:10 martinezlc99

Normally, if a .robocop file is present, Robocop should use it. Is this not happening for you?

I'm not entirely sure how this works with Robocop—whether a pyproject.toml file would cause the .robocop file to be ignored, or vice versa, or if both files are loaded. I’d need to analyze this further.

Currently, there’s no setting in RobotCode to specify which file Robocop should use. However, this could be implemented. Feel free to turn this question into an enhancement request.

d-biehl avatar Oct 30 '24 21:10 d-biehl

@d-biehl - you are correct. I am not sure of the specifics of how robotcode uses robocop, but I guess I was hoping it would analyze each file as if it was running in the same directory as the file, and hence finding the "local" .robocop configuration.

If however, it just analyzes all files at once (presumably starting at the project root), then it appears robocop doesn't support discover of configurations this way - see MarketSquare/robotframework-robocop#1134

martinezlc99 avatar Oct 31 '24 02:10 martinezlc99

Yeah, that seems to be the case! Both the issue and the related one are still open. Right now, the only solution I see is using disablers for files where you want different settings. But this approach would require setting it up for each file individually, which isn’t ideal if you’re dealing with a lot of files.

I’m currently in the process of reworking the entire static code analysis setup for RobotCode, one of the goals is to make it runnable directly from the command line. Part of this rework also includes rethinking how Robocop is integrated, so there's a chance to approach things differently here.

It’d be great if you could share a bit more about what you’re looking to achieve or what requirements you have in mind. That way, I can get a clearer picture and see if we can incorporate those needs in the new setup. What’s your vision?

d-biehl avatar Nov 03 '24 21:11 d-biehl

Hi @d-biehl!

Right now, the only solution I see is using disablers for files where you want different settings. But this approach would require setting it up for each file individually, which isn’t ideal if you’re dealing with a lot of files.

This may be an option...we will look into this...thank you.

It’d be great if you could share a bit more about what you’re looking to achieve or what requirements you have in mind. That way, I can get a clearer picture and see if we can incorporate those needs in the new setup. What’s your vision?

We are creating a Robot Framework "library" which will have both "public" and "private" keywords in various .resource files. The "private"" keywords are largely autogenerated, but not necessarily 100%.

The idea is to have a .robotcop file in the "private" folders, where linting would be less strict (no documentation sections, etc). The "public" keywords would follow the project .robotcop configuration. Since robocop doesnt yet support this use case, I was wondering if robotcode itself could help. When parsing a file for robocop linting, it could behave as if running the robocop CLI from the same folder in which the analzyed file is. In this manner, robotcop would find the "closest" configuration and use it.

By the way, the same idea would apply to the formatter, robotidy.

Not sure if this makes sense. If you open to collaborators, I would be glad to help.

Thanks for considering...

martinezlc99 avatar Nov 04 '24 23:11 martinezlc99

I will chim in. I am currently working on merging two tools - Robotidy and Robocop into one (named Robocop). This may greatly change some things, thats why I would be careful with integrating with us in close future :) But I can say already (since I just implemented it) that Robocop will read multiple configuration files (closest to currently analysed source file). Currently new tool only support pyproject.toml and robocop.toml (Robocop.toml is read first. If both are found, only one is read).

Also our interface changes. We dont have 'api' in new version as its not needed, thanks to improved architecture. But when I will be further into development I will think how other tools may use robocop more easily (if I didnt miss anything important etc).

And side note - Robotidy should already support multiple configuration files (I reuse similar approach but improved upon it for new tool).

bhirsz avatar Nov 07 '24 22:11 bhirsz