8.0.0 Changes

[ikagod]

Ikabot Version 8.0.0 Codebase Changes

Hello Ikabot Contributors,

We have decided that the Ikabot codebase is due for a rework. This means that after this update, Ikabot should be more stable and work better on different platforms. It will also mean, unfortunately, that many breaking changes will be necessary. Your forked repositories will probably need a refactor as well, and you might have to log into Ikabot again after a long time of not logging in. It also means that you will have to set up your Telegram bots with Ikabot again.

Key Points

• Codebase-wide support for static type checking: Starting from this version of Ikabot onwards, the codebase will support static type checks (to some extent). This means that it will be easier for you to write your own custom Ikabot code and modules and it will also make it easier to write code for the members of the Ikabot-Collective. Static type checks will allow your IDE (VS Code, PyCharm etc..) to infer function return types and provide appropriate auto-complete suggestions.

• Logging rework: The logging module has been redesigned before with very bad practical results. For this reason we will redesign it again to be significantly more simple. Ikabot will from this version onwards use logging module from python's standard library.

• Session data rework: After this version of Ikabot, session data will no longer be stored in encrypted lines within the .ikabot file. Instead, the .ikabot file will be plaintext and it will contain data in a JSON format. This will allow Ikabot tasks to talk to each other, even if they are running on different accounts. Whether the cookies will be stored encrypted within this file or in plaintext is a decision we are still in the process of making. THIS WILL MEAN THAT YOU WILL HAVE TO LOG INTO IKABOT AGAIN AND GENERATE NEW COOKIES AND TELEGRAM TOKENS. THIS IS A BREAKING CHANGE!

• Ikabot function module structure: Every Ikabot function module will from now on have two significant components:

  • The configurator function, which will be called by the scheduler process (Main Menu process), that will ask the user for input and return a dictionary containing the keyword arguments that will be passed to the task function for execution.
  • The task function, which will run concurrently in the background along other tasks either on the Main Menu process or on a separate executor process.

  This will open the door for saving task configurations and re-scheduling them again later at the user's command.

• Mode of module execution: Ikabot will now no longer run every module in a separate process. Instead, Ikabot will have two modes of execution:

  • Background-Executor: Where new Ikabot tasks will be scheduled for execution (configured) by the "Main Menu" process (the one that is run by the user when they run Ikabot initially) and actually executed by a "Background Worker" process in a concurrent fashion with other tasks.
  • Main-Menu-Executor: Where the target module will be both scheduled (configured) and executed on the Main Menu process. This will usually be the case on systems where spawning a background process is impossible.

  We have yet to decide on whether to use the asyncio package from the python standard library or to use threading for concurrent task execution.

• Command line arguments: Predetermined input will no longer be the only command line argument option. It is far too buggy and unreliable. From now on, predetermined input will be one of multiple different command line options. Ikabot tasks will also be configurable using command line arguments. THIS MEANS YOUR PREVIOUSLY SAVED PREDETERMINED INPUT COMMANDS WILL HAVE TO BE MODIFIED.

Action Items for Contributors

• Add support for static type checking codebase-wide
• Rework Ikabot logging system to use logging #264
• Decide on whether or not to use encryption at all for the .ikabot file
  • Rework the session data system to use plaintext JSON in the .ikabot file
• Bring structure to every Ikabot function module, separate configurator function from task function
• Decide whether to use asyncio or threading for concurrent task execution
  • Implement two new modes of execution: "Background-Executor" and "Main-Menu-Executor"
• Implement task configuration via command line arguments.
• Remove the use of gettext in the whole project

Final Notes

We encourage all contributors to actively participate in this exciting phase of Ikabot's development. Your insights and assistance are invaluable, and we look forward to collaborating on version 8.0.0.

Share Your Feedback: If you have any thoughts, suggestions, or concerns, please feel free to share them in the comments. Your feedback is crucial in making Ikabot even better.

Thank you for your continued support and contributions!

[susikaman]

I support the rework of the session data system. It just feels pointless to have it encrypted while there's no reason to. Instead, it would be a great benefit to be able to modify it by hand if one wishes to do so, this would also make it possible to identify an .ikabot file from a multitude of backups.

Using commandline arguments instead of user predetermined input does sound like a more optimal way to launch Ikabot with preferred tasks. Although the rework of existing predetermined input commands sounds horrifying (I have like 15 of these to modify, of which nearly all of them are more or less different), it would make things a lot more stable as a commandline argument can't go wrong due to misplaced order. Therefor, I support that as well despite the fact that this will cause me a lot of additional work lol.

The rest, I'll wait and see how it looks like before I can say anything. Overall the 8.0.0 changes sound really promising and fresh!

[coecharlin]

• Decide whether to use asyncio or threading for concurrent task execution
  Between the two options, which one did you choose? I ask because I am improving a feature that will have this type of need and, to maintain the project standard, I may need to adjust my choice.

[susikaman]

• Decide whether to use asyncio or threading for concurrent task execution
  Between the two options, which one did you choose? I ask because I am improving a feature that will have this type of need and, to maintain the project standard, I may need to adjust my choice.

Which would you personally prefer? Give your thoughs

[ElieTaillard]

Yes, don't hesitate to give your opinion @coecharlin

[ElieTaillard]

@ikagod Do you want to create a separate branch for the 8.0.0 changes?

[susikaman]

I'll give a vote for threading. I've experienced with threading and it's lock feature to prevent duplicate functioning between threads. Threading lock would be the perfect solution for concurrent tasks switching towns which is occationally causing problems. This would be an easy way to have tasks perform operations one at a time.

[coecharlin]

Threading lock would be the perfect solution for concurrent tasks switching towns which is occasionally causing problems.

I'm using Threading so that each execution in a different city doesn't interfere with each other, but as I don't have experience in the area, I'm not sure which one would be ideal for the project.

[coecharlin]

One difficulty I am currently having with using Threading is the issue of dealing with the timer to execute the next task after finishing, it seems that Threading does not respect the timer that is being executed haha, I still haven't understood this

[ElieTaillard]

One difficulty I am currently having with using Threading is the issue of dealing with the timer to execute the next task after finishing, it seems that Threading does not respect the timer that is being executed haha, I still haven't understood this

Indeed, managing timers with threading can be tricky. Threading operates by managing multiple execution threads, which can sometimes lead to synchronization issues and timing mismatches, such as missing scheduled timeouts.

Switching to asyncio could potentially resolve these issues. Unlike threading, asyncio uses a single thread and cooperative multitasking, which makes it easier to handle tasks that depend on precise timing. With asyncio's async def coroutines and asyncio.sleep, tasks can be scheduled to run after a specified delay without blocking the main thread.

Asyncio could be a better option, however, this requires structuring the code around the asynchronous model (async def, await, etc.), which may require some additional thought

[ikagod]

We will be using threading mainly because of simplicity.

[susikaman]

We will be using threading mainly because of simplicity.

Lol honestly, I was just working on a private project trying to utilize asyncio in it. Holy hell, it literally forced me to re-write the entire project to get things working properly, and it made the whole thing so confusing and messed up that I just gave up on it. I also vouch for threading, it seems way easier.

[BigMax23]

Hi everyone! What’s the current status of version 8.0? Are you making progress? Is there any hint of a release date yet?

[ikagod]

Hi everyone! What’s the current status of version 8.0? Are you making progress? Is there any hint of a release date yet?

Unfortunately not yet because I've been busy with work but I am looking to pick up development on it soonish.

[ikagod]

There hasn't been any news about this in a while, has there? Almost 8 months and very little progress.

It's unfortunate but I have a lot less time to work on ikabot in comparison to how much I used to. I might just reduce the scope of this issue and then work towards implementing it.
I just merged a PR that added typing to getJson.py, which is the most important module to add typing to due to the fact that it is the module that converts JSON objects from ikariam into the python dicts that ikabot uses. It's not quite what I promised in this issue (typing codebase-wide) but it's something. It will have to do for now.