gpt-engineer: Incompatibility with Python 3.8 and 3.9: TypeError in file_store.py

Policy and info

Maintainers will close issues that have been stale for 14 days if they contain relevant answers.
Adding the label “sweep” will automatically turn the issue into a coded pull request. Works best for mechanical tasks. More info/syntax at: https://docs.sweep.dev/

Expected Behavior

The project documentation states support for Python versions 3.8 - 3.11. I expect the software to run without syntax errors in these versions.

Current Behavior

When attempting to run the project in Python 3.9, a TypeError occurs in file_store.py due to the use of the union operator | in type hints.

Failure Information

The project uses a syntax feature (str | Path) that is only available in Python 3.10 and later, leading to incompatibility with Python 3.8 and 3.9.

Steps to Reproduce

Set up the project in a Python 3.9 environment.
Follow the installation and setup instructions.
Attempt to run the project, leading to the TypeError in file_store.py.

Failure Logs

Traceback (most recent call last):
  File ".../Scripts/gpt-engineer", line 3, in <module>
    from gpt_engineer.applications.cli.main import app
  ... (additional traceback)
  File ".../file_store.py", line 8, in FileStore
    def __init__(self, path: str | Path | None = None):
TypeError: unsupported operand type(s) for |: 'type' and 'type'

About this issue

Original URL
State: closed
Created 7 months ago
Comments: 16

Most upvoted comments

@similato87 Read the error log of the precommit check. Run black to format the code.

ErikBjare on Dec 16, 2023

@ATheorell Done in #908.

Being backwards compatible can’t harm

That’s not entirely true. Dependencies will at some point (probably soon, given upcoming EOL) drop support for Python 3.8 (if some haven’t already), leaving us pinned with old versions.

even if we make version requirement stricter

If version requirement is made stricter, there’s no reason to use the old syntax.

pyupgrade should be run when the decision is eventually made to drop support for older versions. This would automatically update old syntax to the new one.

@ErikBjare l, I concur with your insights regarding the trade-offs of backward compatibility. While supporting older Python versions is beneficial for wider accessibility, it does bring the challenge of dependency management. As you mentioned, dependencies will eventually drop support for older versions like Python 3.8, and this could limit us to outdated packages.

Adopting pyupgrade at the appropriate time is a forward-thinking strategy. In the interim, maintaining support for older versions could be a pragmatic approach, with the understanding that we’ll transition as dependencies evolve. Regular releases could be planned to align with these dependency updates, ensuring a smooth transition for users.

similato87 on Dec 16, 2023

@similato87 You need to create a fork, push your changes to that fork, and submit a PR from that fork. The contribution guidelines seem to miss this fact.

ErikBjare on Dec 16, 2023

Thanks for reporting, we’ll take a decision on either making the python requirement stricter or changing the syntax

ATheorell on Dec 14, 2023