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

User modern rules_python and expect users to provide the mypy library themselves #82

Closed
wants to merge 0 commits into from

Conversation

martis42
Copy link
Contributor

Some time ago I created a fork of this project to be able to utilize it in a project of mine which uses a fairly recent version of rules_python. However, the current version of this project is not compatible modern rules_python versions. Since the fork worked for me well for some time now I want ti contribute this to the main repo so everybody can profit from it.

The main changes are:

  • Some smallish refactoring
  • Rewrite project to be compatible to modern rules_python versions. rules_python nowadays relies on providing fully resolved requirement files. Also pip_install will be removed. Only pip_parse will work in the future.
  • Use a hermetic Python toolchain for development in this project.
  • Expect users to provide the mypy library themselves
    • This project can't offer a version which fits all needs
    • Injecting a fully resolved requirements file for the desired mypy version is possible. In fact this design was tested by me (see intermediate commits). But it is clunky and needlessly complex.
    • Expecting the user to provide the mypy library via a label_flag is an elegant interface and fits into the pattern how the project already allows setting a mypy config.
    • Injecting the tool for a rule set is not a novel idea, but is also done in other rule sets like rules_webpack, rules_jest and others.

I believe these changes are also an important building block to enable bzlmod for this project, which would make using it even more convenient. If this PR is accepted I would also try to help with adopting bzlmod.

I am looking forward to your review.

@martis42
Copy link
Contributor Author

@alexeagle pinging you directly since you created several commits in the recentish history of this project. Any opinion on this contribution?

README.md Outdated Show resolved Hide resolved
BUILD Outdated
Comment on lines 19 to 20
# No usable default. Force users to inject mypy.
build_setting_default = "//tools:empty_library",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we just use a default mypy version? then it will still "just work" for anyone who pull this in and just tries it, while still allowing for easy overriding

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend not doing so. The reason is, that using a default mypy requires fetching it via rules_python and pip_parse, which makes using this project via a WORKSPACE file quite clunky. Essentially this would require calling the multiple steps to load mypy with some names hard coded in this project.
On the other hand, most likely only Python users will use this project at all, so adding mypy to their deps and setting the label_flag are literally 2 lines of work.

.bazelrc Outdated
@@ -0,0 +1 @@
build --//:mypy=//third_party:mypy
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we use a valid default for the mypy version then we don't have to set this here


# buildifier: disable=function-docstring
def repositories():
excludes = native.existing_rules().keys()
versions = struct(
rules_python = "0.18.1",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we jump straight to 0.27.1? That is the last version that supports Bazel 5. Bazel 4 is already end-of-life, so I don't think we need to support it anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want that done in one big step with the other changes, i can do so

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either way! We can always upgrade further in another PR

@adzenith
Copy link
Collaborator

adzenith commented Feb 4, 2024

Did you mean to close this? Looks like GitHub auto-closed it.

@martis42
Copy link
Contributor Author

martis42 commented Feb 4, 2024

@adzenith The PR was closed due to me updating my fork to adapt to the latest changes in this project. I created a new PR #98

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

Successfully merging this pull request may close these issues.

2 participants