[AGPT-688] NiceGUI Prototype

[majdyz]

This is a very early prototype of the front-end code generation.

The current implementation is still super basic, but the idea is to evaluate early if this is possible. The hypothesis is if we can build a small fully working UI component, we can utilize more sophisticated agentic prompting.

I created a video of the quick run-through of the code and how to test it https://www.loom.com/share/b331582fa2694ece8594c00ae78c71e5?sid=59b6baa6-ca9b-4f46-bb7e-76a82b1fce98

These are the possible next steps:
https://www.notion.so/auto-gpt/Front-end-Codex-Plan-abf6c1d990104d23b758960cbaea26f9

[linear]

AGPT-688

[Swiftyos]

It's not very easy to try out.

Can you make a click command that I can pass in an app name description and it generates the code and runs the ui.

That would make it much easier to understand what it can do and how its used.

[Torantulino]

Let's avoid merging this until it's more mature, so this PR should probably be a draft, or merged to a more permanent branch.

[ntindle]

@Torantulino why wait, this isn't in any code paths that are executed by default

[Torantulino]

@Torantulino why wait, this isn't in any code paths that are executed by default

Right I see, that's fine then. As long as it won't effect our users then it's okay to merge.

[Swiftyos]

/review

[qodo-merge-pro]

PR Review

⏱️ Estimated effort to review [1-5]	4, due to the extensive changes across multiple files, including the addition of new functionality, integration with external libraries, and modifications to existing code. The complexity and breadth of the changes require a thorough review to ensure functionality, performance, and security.
🧪 Relevant tests	Yes
🔍 Possible issues	Possible Bug: The use of async in the create_sample_app function in 'codex/tests/frontend_gen_test.py' might not handle exceptions properly if the database operations fail. Consider adding exception handling around the database calls.
	Performance Concern: The function create_sample_app in 'codex/tests/frontend_gen_test.py' and similar functions make multiple asynchronous database calls in sequence, which could be optimized by using asyncio.gather to run them concurrently.
🔒 Security concerns	No

Code feedback:

---

relevant file	codex/tests/gen_test.py
suggestion	Consider using asyncio.gather for concurrent database operations in create_sample_app to improve performance. This change allows multiple I/O-bound tasks to run concurrently, which can significantly reduce the waiting time for I/O operations to complete. [important]
relevant line	app = await get_app_by_id(user_id, app_id)

---

relevant file	codex/develop/code_validation.py
suggestion	Add error handling for the validate_code function to manage exceptions that might occur during the code validation process, such as connectivity issues with external services used in validation. This will make the function more robust and reliable. [important]
relevant line	route_errors_as_todo: bool,

---

relevant file	codex/develop/agent.py
suggestion	Refactor the process_api_route function to reduce its complexity by breaking it down into smaller, more manageable functions. This can improve readability and maintainability. [medium]
relevant line	lang: str = "python",

---

relevant file	codex/tests/frontend_gen_test.py
suggestion	Implement caching for database queries in the create_sample_app function to enhance performance, especially when dealing with repeated queries for the same data. [medium]
relevant line	app = await get_app_by_id(user_id, app_id)

---

[ntindle]

Let’s get this merged to keep moving without constant rebasing for zamil

[qodo-merge-pro]

CI Failure Feedback

Action: test

Failed stage: Install Python dependencies [❌]

Failure summary: The action failed due to a mismatch between the pyproject.toml file and the poetry.lock file. The pyproject.toml file has changed significantly since the poetry.lock file was last generated, which requires updating the lock file by running poetry lock [--no-update].

Relevant error logs: 1: ##[group]Operating System 2: Ubuntu ... 538: Installing Poetry (1.8.2): Creating script 539: Installing Poetry (1.8.2): Done 540: Poetry (1.8.2) is installed now. Great! 541: You can test that everything is set up by executing: 542: `poetry --version` 543: Creating virtualenv codex-ORswSzyp-py3.11 in /home/runner/.cache/pypoetry/virtualenvs 544: Installing dependencies from lock file 545: pyproject.toml changed significantly since poetry.lock was last generated. Run `poetry lock [--no-update]` to fix the lock file. 546: ##[error]Process completed with exit code 1.

---

✨ CI feedback usage guide:

---

The CI feedback tool (/checks) automatically triggers when a PR has a failed check.
The tool analyzes the failed checks and provides several feedbacks:

• Failed stage
• Failed test name
• Failure summary
• Relevant error logs

In addition to being automatically triggered, the tool can also be invoked manually by commenting on a PR:

/checks "https://github.com/{repo_name}/actions/runs/{run_number}/job/{job_number}"

where {repo_name} is the name of the repository, {run_number} is the run number of the failed check, and {job_number} is the job number of the failed check.

Configuration options

• enable_auto_checks_feedback - if set to true, the tool will automatically provide feedback when a check is failed. Default is true.
• excluded_checks_list - a list of checks to exclude from the feedback, for example: ["check1", "check2"]. Default is an empty list.
• enable_help_text - if set to true, the tool will provide a help message with the feedback. Default is true.
• persistent_comment - if set to true, the tool will overwrite a previous checks comment with the new feedback. Default is true.
• final_update_message - if persistent_comment is true and updating a previous checks message, the tool will also create a new message: "Persistent checks updated to latest commit". Default is true.

See more information about the checks tool in the docs.