Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative/Package imports throwing error #56

Open
andrewmiranda2001 opened this issue Mar 17, 2025 · 1 comment
Open

Relative/Package imports throwing error #56

andrewmiranda2001 opened this issue Mar 17, 2025 · 1 comment

Comments

@andrewmiranda2001
Copy link

Hello,

I have a nested package structure for all of my request/response types:

API/
client/
types/
generic/
...
request/
...
response/
...

At first, I had absolute imports such as from API.client.types.generic.crud import GenericType which would fail:
ModuleNotFoundError: No module named 'API.client.types.generic'

So, I changed them to be relative imports simply for the sake of getting this automation up and running and got another error:
from ..generic.crud import GenericType
ImportError: attempted relative import beyond top-level package

This is the python script I wrote for reference:

from pydantic2ts import generate_typescript_defs
import os

API = os.path.join(os.path.dirname(__file__), "API\\client\\types")
FRONTEND = os.path.join(os.path.dirname(__file__), "frontend\\src\\api\\types")
COPY_DIRS = ['generic', 'request', 'response']


def main():
    for dir in COPY_DIRS:
        if not os.path.exists(os.path.join(FRONTEND, dir)):
            os.makedirs(os.path.join(FRONTEND, dir))
        for file in os.listdir(os.path.join(API, dir)):
            if file.endswith(".py") and not file.startswith("__"):
                output_file = os.path.join(FRONTEND, dir, file.replace(".py", ".ts"))
                if not os.path.exists(output_file):
                    with open(output_file, 'w') as f:
                        pass
                
                print(f"Generating {output_file}")
                generate_typescript_defs(os.path.join(API, dir, file), output_file)


if __name__ == "__main__":
    main()

Is there a way to skip over imports if they fail? Or to just write the relative imports even if it leaves the scope of the current transpilation? Because yes, the error is rightly being thrown, but if the relative imports were transpiled, by the end of the script they would be resolved anyways.

I saw you are working on some other fixes for multi-file generation, so I hope this is something that can be included in there. It isn't the best practice to have all of your requests and responses mushed into one file anyways.

Thank you!

@andrewmiranda2001
Copy link
Author

andrewmiranda2001 commented Mar 17, 2025

I also was able to transpile one of the files successfully:

class TypedObjectBase(BaseModel):
    name: str
    description: Optional[str] = None

class TypedObjectUnspecified(TypedObjectBase):
    extension: Optional[CONFIGURED_EXTENSIONS] = None
    label: Optional[str] = None

class TypedObjectSpecified(TypedObjectUnspecified):
    extension: CONFIGURED_EXTENSIONS
    label: str

However, the transpiled code seems to completely ignore the hierarchy of the original code, while you would expect the output to look like this:

interface TypedObjectBase {
  name: string;
  description?: string;
}

interface TypedObjectUnspecified extends TypedObjectBase {
  extension?: ConfiguredExtensions;
  label?: string;
}

interface TypedObjectSpecified extends TypedObjectUnspecified {
  extension: ConfiguredExtensions;
  label: string;
}

However, it generates out to look like this:

export interface TypedObjectBase {
  name: string;
  description?: string | null;
}
export interface TypedObjectSpecified {
  name: string;
  description?: string | null;
  extension: "x" | "y" | "z" ;
  label: string;
}
export interface TypedObjectUnspecified {
  name: string;
  description?: string | null;
  extension?: ("x" | "y" | "z") | null;
  label?: string | null;
}

I'd like for the outputted types to have the same semantic meaning as the original, otherwise it ruins all of my nice hierarchical types I worked so hard on!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant