Alt parsing

[podcherklife]

So, I've got a weidu.log with several hundreds of entries. This PR is the result my attempts to use that log to reinstall EET. It works for me(requires some manual input for mods that use READLN commands though), but I am pretty sure I might have broken some use cases.

Points of interest:

• Changed weidu arguments from --yes --ask-only {component} to --force-install
  For whatever reason --yes --ask-only was not working with dlc-merger for me.
  With --force-install though weidu produces the exact same weidu.log as the one that was used as an input.
• Interaction with weidu process is rewritten.
  --force-install makes it so that inputting [Y] is no longer required, but then there is an inherent problem with READLN commands, and I don't think there can be a general solution for that. This implementation seems to mostly work(i.e. works for me) but does not handle the case when user input is incorrect and weidu rejects it.
• Added an option to stop installation if warnings are encountered
• No tests...

[dark0dave]

Hmm interesting this was originally how I did this. You have cleaned up the flow alot thanks! Let me have a look, at this.

[dark0dave]

The --yes and --ask-only triggers the user input. Issue with this is that, sub-components can fail to install the right version. Sub-component information is not well stored in the weidu log. I attempted to parse some of it, in the log component.

Did you try with any mods that had sub-components? @podcherklife ?

[dark0dave]

If you could avoid println!() and use the logger, that would be most appreciated.

[dark0dave]

If user input is incorrect we should just panic!(), I think its fine. As the logs are installed in order, panicing on incorrect user input is completely acceptable.

[dark0dave]

There is a few clippy errors too you can fix them with the following:

cargo clippy --fix --allow-dirty --allow-staged

[podcherklife]

The --yes and --ask-only triggers the user input. Issue with this is that, sub-components can fail to install the right version. Sub-component information is not well stored in the weidu log. I attempted to parse some of it, in the log component.

Did you try with any mods that had sub-components? @podcherklife ?

Frankly, I am not exactly familiar with the terminology in IE modding.
Do you mean the SUBCOMPONENT thing? If so, then yes, it seems to work.
Subcomponents are just components that happen to have an additional logic "we belong to the same group and only one of us can be installed", aren't they?
The DLC merger that I've mentioned has a few subcomponents and --force-install installs the expected one. Now then if the log contains multiple subcomponents belonging to the same group, that would get tricky, but I guest that's on weidu. Or on user.

I might be misunderstanding something though.

But again, I've tested this on a log with ~500 entries and the output log is exactly the same as the input log.

[podcherklife]

If user input is incorrect we should just panic!(), I think its fine. As the logs are installed in order, panicing on incorrect user input is completely acceptable.

We don't know that however. Its the mod authors who handle input and validation. If there was some kind of AWAITING_INPUT marker from weidu, then we could do something like that but alas, there is no such thing(and I did not manage to build weidu locally to try to add it =) ).
I see two ways of doing this:

• Pipe all user input to weidu and all weidu output to user
  Well, then there gonna be no easy wat see the installer information(how many mods have been already installed and how much time did it take).
• Build a proper ui(console or whatever) with two tabs, one would be for weidu i/o and another would be for mod installer controls.
  May be, but that's kinda like building a proper mod manager. Now I actually have no idea of what your vision is, so may be I am missing something but personally I am using this installer to automate reinstallation, so that I do not have to press buttons in console or deal with Project Infinity more that I have to.

Now that I think of it it might actually be possible to programmatically figure out if weidu process is waiting for input(at least on linux) by using strace, but, well, that's kinda stupid.

[dark0dave]

If user input is incorrect we should just panic!(), I think its fine. As the logs are installed in order, panicing on incorrect user input is completely acceptable.

We don't know that however. Its the mod authors who handle input and validation. If there was some kind of AWAITING_INPUT marker from weidu, then we could do something like that but alas, there is no such thing(and I did not manage to build weidu locally to try to add it =) ). I see two ways of doing this:

* Pipe all user input to weidu and all weidu output to user
  Well, then there gonna be no easy wat see the installer information(how many mods have been already installed and how much time did it take).

* Build a proper ui(console or whatever) with two tabs, one would be for weidu i/o and another would be for mod installer controls.
  May be, but that's kinda like building a proper mod manager. Now I actually have no idea of what your vision is, so may be I am missing something but personally I am using this installer to automate reinstallation, so that I do not have to press buttons in console or deal with Project Infinity more that I have to.

Now that I think of it it might actually be possible to programmatically figure out if weidu process is waiting for input(at least on linux) by using strace, but, well, that's kinda stupid.

Yes I'd like to avoid strace everything. Agreed it seems like adding back in all the choices made it a bit more unstable. I don't really wish to add a GUI, my vision would be so ffi out to weidu rather than all this command line text parsing. Some thing like this: https://github.com/zshipko/ocaml-rs.

[dark0dave]

Pipe all user input to weidu and all weidu output to user

I was effectively doing this.

[dark0dave]

@podcherklife thank you so much for your pr!