Move `Revision` enum from `schemas/common.py`

[franciszekjob]

Feature Request

Currently Revision is stored in schemas/common.py. There are circular import errors when storing it in models/typed_data.py. Revision should be moved to either separate file or models/typed_data.py after solving circular import errors.

[ScottyDavies]

Hello @franciszekjob can i work on this?

[franciszekjob]

Hey @ScottyDavies, you're welcome to open a PR for it.

[ScottyDavies]

out of curiosity do contributors get paid? @franciszekjob

[franciszekjob]

@ScottyDavies At this moment, we do not sponsor this issue nor any other issues through OnlyDust.

[KevinMB0220]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I have experience in all the languages ​​used in the issue, so it would be easier for me to achieve it.

How I plan on tackling this issue

To resolve the circular import issue when moving Revision to models/typed_data.py, you can refactor the imports by placing any problematic imports within functions or methods to delay them, thus breaking the circular dependency. Alternatively, you could move the Revision class into its own module (e.g., models/revision.py), allowing both schemas/common.py and models/typed_data.py to import it without issues. This isolates the Revision class, avoiding direct dependencies between the two modules.

[ALEXUSCR-27]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I am a junior software engineer and I have good experiences with python, I worked with this language in my last internship where I had some import problems in my project that was necessary to fix.

How I plan on tackling this issue

Probably, some libraries will need a refactor to fix other import errors before I move the enum to a separate file. Having the enum in a separate file may fix some future errors with other libraries that could need to use it.

[DioChuks]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

Full-Stack Engineer: Deep Understanding of Module Structures: My experience with multiple languages like Python and JavaScript equips me with the ability to understand and refactor module structures effectively. Circular imports are a common challenge in both Python and JavaScript, and my problem-solving skills can help identify the best approach, whether through restructuring or using lazy imports.

Leverage: Use my knowledge of module systems in Python and TypeScript to identify where the circular dependencies are occurring and determine the best way to isolate the Revision enum without breaking functionality.

Experience in Object-Oriented Programming: My Python and PHP background implies a strong foundation in object-oriented programming, which will help me think about modularity and separation of concerns. This can be crucial when moving the Revision enum to a dedicated file or reorganizing the project structure.

Leverage: Apply object-oriented design principles to reorganize the project into a more modular structure. By separating shared components into dedicated modules, you can avoid circular imports and improve code maintainability.

Problem Solving and Refactoring Expertise: Given my strength in problem solving, i'll be able to quickly identify patterns of redundancy or inefficiency in the current structure. Refactoring the circular import issue requires both technical knowledge and creative problem-solving to ensure the solution is clean and scalable.

Leverage: Apply problem-solving techniques to identify whether breaking the circular dependency through restructuring or using local imports is the most effective solution. My ability to debug complex issues will help streamline this process.

Conclusion: With my background in Python, PHP, JavaScript, TypeScript, and strong problem-solving abilities, I also have a degree in computer science, i am well-equipped to refactor the project in a clean and efficient manner. I'll be able to isolate and move the Revision enum while solving circular imports, ensuring the codebase remains maintainable and scalable for future growth.

How I plan on tackling this issue

To address the issue of moving the Revision enum from schemas/common.py while solving the circular import errors, here’s how I would approach the problem:

Firstly, It's to Understand the Cause of Circular Import: Circular Import: Circular imports occur when two or more modules depend on each other directly or indirectly. In this case, it seems that both models/typed_data.py and schemas/common.py depend on each other, which is causing the circular import issue. Revision Enum: Revision is an enum that is used in both schemas/common.py and models/typed_data.py, and moving it requires restructuring to avoid circular dependencies. Secondly, to investigate Import Dependencies: Check Dependencies: I will Inspect both models/typed_data.py and schemas/common.py to see where and how Revision is being imported and used. This will give me insight into how the circular import is created. Identify Other Dependencies: I'll check for other dependencies between these modules that might also contribute to the circular import. I have an option for resolving the circular import issue while moving the Revision enum:

Moving Revision to a Separate Module Creating a New File: Move the Revision enum to a new file (e.g., schemas/revision_enum.py or models/revision_enum.py). This isolates the enum in its own module, reducing the risk of circular imports:

schemas/revision_enum.py

from enum import Enum

class Revision(Enum): DRAFT = "draft" FINAL = "final" I can import Revision Where Needed: After moving Revision, I can import it in both models/typed_data.py and schemas/common.py:

models/typed_data.py

from schemas.revision_enum import Revision This method keeps Revision separate and reduces complexity, which may eliminate the circular import.

[franciszekjob]

@DioChuks please open a PR if you want to contribute, thanks.