Difference between TagUI vs TagUI for Python? - different target users

[ck81]

@kensoh, really excited by your new TagUI-Python as it opens up a whole new spectrum of possibilities in RPA applications, especially interfacing with those established machine learning and deep learning Python frameworks.

Not sure if the following have been documented somewhere,

1. I looked at the command sets between the two.
   TagUI: https://github.com/kelaberetiv/TagUI#steps-description
   TagUI-Python: https://github.com/tebelorg/TagUI-Python#api-reference
   It seems that they are about the same. So is it correct to say that almost all the commands in TagUI are supported in TagUI-Python?

2. Can you highlight some major differences between the two (besides one written in TagUI script, and the other in Python)?

[kensoh]

HI CK @ck81 thanks for your support and encouragement! Yes, I hope to bring TagUI automation features to a new user demographic - Python beginners to experts, data analytics folks, machine learning engineers, data scientists, etc. Below are comments on the commands set.

In this project's design, I try to bring over as much of the UI automation steps from TagUI as reasonably possible. Some steps will be not applicable because we are now in Python environment. For eg // or live step, py and r steps have no meaning in the context of Python environment.

There are also frame and popup step which is not portable over because TagUI live mode technically doesn't support that. api step is meaningless too, as Python's requests package is the typical way to access API on Python, with a mature ecosystem of tutorials and tried-and-tested robust functions.

[kensoh]

The major difference would be TagUI for Python only has a subset of TagUI's features. TagUI is more like a framework by itself with features such as modules, repositories, datatables, auditing.

TagUI for Python is more like a foundational building block which Python users can develop to add their own preferred implementations of repositories, datatables, auditing etc as needed.

Though the features are lesser, when the project is less opinionated, it allows broader usage and easier customisation according to individual needs. Also, having the UI automation features of TagUI is already a big win for Python users, as the Python ecosystem amplifies its strengths and benefits.

The other difference as you pointed out would be the human languages syntax supporting 21 human languages versus TagUI for Python the functional declarations are base on English words.

[kensoh]

Forgot to add, headless invisible mode is not enabled yet in TagUI for Python. It is technically possible to add a flag to support Chrome in headless mode, but I have not found a strong use case to do that.

Since the visible mode has its own Chrome TagUI user profile and session, it will not disrupt the user from working on something else while automation is running. Also, headless or not the resource consumption should be negligible.