Closed Sejsel closed 1 month ago
I believe, at least for starter, it'd be better to keep the current "console" capabilities of GW2EIParser as to not cause a massive breakage with one release to the other and give time to console users to properly migrate.
I'm perfectly fine with not using the .conf file in the CLI, the console stuff in GW2EIParser is more an afterthought than a well thought solution, the conf file makes much sense for the "Save"/"Load" features of the setting panel.
"Store API data somewhere" You mean the GW2 API caches? If yes, then yes, we should avoid duplication in the project, they can't remain in GW2EIParser.
I believe you can already specify an output directory via OutLocation and setting SaveAtOut to false.
As a standalone, ConsoleProgram is not really necessary, its content can be moved out.
I believe, at least for starter, it'd be better to keep the current "console" capabilities of GW2EIParser as to not cause a massive breakage with one release to the other and give time to console users to properly migrate.
Yeah, I definitely do not want to release anything that would remove functionality. On the other hand, changing from mono to dotnet 8 is involved enough that I believe we can afford to change the CLI usage a little bit.
"Store API data somewhere" You mean the GW2 API caches? If yes, then yes, we should avoid duplication in the project, they can't remain in GW2EIParser.
Yeah, I meant those caches. I need to look into how they are stored, actually, all I see is that it clearly isn't cached the way I set it up as it downloads the data again on every run.
I believe you can already specify an output directory via OutLocation and setting SaveAtOut to false. Yeah, that should work, I missed that when I was looking at the settings earlier, should be easy to add CLI arguments for that.
As a standalone, ConsoleProgram is not really necessary, its content can be moved out. I agree, I just went for the fast option there without thinking about it too mcuh
Currently the expected location for API caches is hardcoded based on the executable's location: https://github.com/baaron4/GW2-Elite-Insights-Parser/blob/411c44d5c5a5847d68315dbe1f5ff84d1cf71912/GW2EIParserCommons/ProgramHelper.cs#L66
Obsolete due to #930.
Now that we have some processing logic split into ParserCommons, I looked at making a console program that can actually be ran on Linux with .NET 8. This basic version works for the most basic scenario without any configuration, but is nowhere near complete.
To achieve feature parity:
Currently, the Windows program relies on WinForms-exclusive property APIs. I feel like within this console version, we might actually be better off by offering all these options as CLI arguments and scrap the file version completely; then we can construct
ProgramSettings
with that and continue as usual.We should use a CLI argument library for this, I don't think it's viable to do it this way
Preferably without duplication (likely needs to be moved into commons, it is possible to set version by inspecting other assemblies within msbuild config)
Improvements I would like:
ConsoleProgram
so that it doesn't do all its logic in the constructor, or just don't use it at all (looking back at it, that may have been the intention, I did have to move that to commons)