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

Extend ivy-lint to everything instead of just the frontends #28448

Closed
vedpatwardhan opened this issue Feb 28, 2024 · 1 comment
Closed

Extend ivy-lint to everything instead of just the frontends #28448

vedpatwardhan opened this issue Feb 28, 2024 · 1 comment
Assignees
Labels
Bounty Issues that are a part of the Bounty Program

Comments

@vedpatwardhan
Copy link
Contributor

vedpatwardhan commented Feb 28, 2024

We're currently using a custom pre-commit lint hook specifically designed for formatting Python files in Ivy's frontend, as detailed in our documentation and implemented in our lint hook repository. This formatter organizes the code into two main sections: helpers and main, sorting functions alphabetically within these sections based on a specific regex pattern.

The task at hand is to adapt and extend this formatter to cater to Ivy's backend and the Ivy Stateful API. Unlike the frontend, where the division is simply between helpers and main functions, the backend and stateful API require a more nuanced approach to accommodate various headers that categorize functions into either the "Array API Standard" or "Extras", among others. This distinction is crucial as it helps in segregating functions that adhere to the standard from those that do not, with new functions being added regularly.

For the backend and Ivy Stateful API, the goal is to maintain the integrity of these headers, such as "Array API Standard", "Autograd", "Optimizer Steps", "Optimizer Updates", "Array Printing", "Retrieval", "Conversions", "Memory", etc., ensuring they remain unchanged. The proposed approach involves sorting functions alphabetically within each section defined by these headers, thereby preserving the organizational structure and clarity regarding the functionalities of each section.

The desired structure for updating the formatter should adhere to the following template, ensuring a clear and organized codebase:

# global imports

# local imports

# Global declarations
<Global variables, mode stacks, initializers, postponed evaluation typehints, etc.>

# Helpers #
# -------- #
<Private helper functions specific to the submodule>

# Classes
<Class definitions within the submodule>

# <function section header 1>
<Alphabetical listing of functions in section 1, including relevant assignment statements>

# <function section header 2>
<Alphabetical listing of functions in section 2>

...
# <function section header n>
<Alphabetical listing of functions in section n>

This structure not only ensures functions are easily locatable and the code remains clean but also respects the categorization of functionalities as per Ivy's standards. The approach was previously attempted in a pull request (#22830), which serves as a reference for implementing these changes.

If you have any questions feel free to reach out to @NripeshN or @KareemMAX

@vedpatwardhan vedpatwardhan added the Bounty Issues that are a part of the Bounty Program label Feb 28, 2024
@NripeshN
Copy link
Contributor

Hey @soma2000-lang
Looks like you are already working on another issue. Could you please choose one issue you want to work on and unassign yourself and delete the comment @ivy-leaves assign me from the issue. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bounty Issues that are a part of the Bounty Program
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants