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

Migrate to Bazel 7 #67

Closed
wants to merge 3 commits into from
Closed

Migrate to Bazel 7 #67

wants to merge 3 commits into from

Conversation

manuelnaranjo
Copy link
Contributor

@manuelnaranjo manuelnaranjo commented Dec 22, 2023

Inspired in #61, I'll migrate to bazel 7 while keeping both bzlmod and non bzlmod support working, only updating the minimal amount of packages to not make the MR too convoluted

Starting to bump to 7.0.0
Now the repo buils with bazel 7.0.0 and no bzlmod yet
Bumping only the needed rules to make the setup work, making sure both
bzlmod and non bzlmod still builds and test as expected
@manuelnaranjo manuelnaranjo changed the title WIP: migrate to Bazel 7 Migrate to Bazel 7 Dec 22, 2023
Copy link
Owner

@rmohr rmohr left a comment

Choose a reason for hiding this comment

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

Took me a little bit to look into it. Sorry for the delay. one question regarding to how we can release this ...

@@ -0,0 +1,24 @@
module(
name = "bazeldnf",
version = "0.6.0",
Copy link
Owner

Choose a reason for hiding this comment

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

Is this a value which we need to bump for releases to match the release tag?

Copy link
Owner

Choose a reason for hiding this comment

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

Maybe something which we can always set to the tag value in the release script with e.g. buildozer?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes so the version is something that gets bumped with a GitHub release and the Bazel central registry (BCR) provided with GitHub workflows to make releasing of new versions trivial, there's a template rule from which every new rule is forking, I need to look into the details and adopt, once we have those hooks a new release for BCR is just a tag in another public GitHub repo

go_deps = use_extension("@bazel_gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")

use_repo(
Copy link
Owner

@rmohr rmohr Jan 25, 2024

Choose a reason for hiding this comment

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

I think the optimum would be if by default we woulds still just download the recompiled dependencies, so that while we can cleanly pull in the whole go stack, by default we don't have to. Having said that, an initial stab on this which only works with recompile is fine as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes so rules_go would become a dev dependency, what other rules are doing is having a public directory in our case it would be bazeldnf and in that directory if someone does bazel build @bazeldnf//bazeldnf/... then the entire path should build.

We would choose to use prebuilt or already built during toolchain registration.

Since I started exploring bzlmod for bazeldnf I also wrote/ported some other rules and learned a lot in the process, I need to close this MR and rebuild based on that, we should make lock file support a chance we introduce once we merge bzlmod.

@manuelnaranjo
Copy link
Contributor Author

manuelnaranjo commented Jan 25, 2024

Took me a little bit to look into it. Sorry for the delay. one question regarding to how we can release this ...

No worries, sorry for not updating the PR and splitting concerns, now that my rules_rpmbuild work as expected I got my bazeldnf fork to a state that it serves our needs pretty well, I need to go back and split my changes so we can merge

@rmohr
Copy link
Owner

rmohr commented Feb 6, 2024

@manuelnaranjo I would love to make bazeldnf fit for bazel 7. Do you think you will have time to separate out the bazel 7 changes?

@manuelnaranjo
Copy link
Contributor Author

@rmohr can't promise much, but I'll try

@manuelnaranjo
Copy link
Contributor Author

Let's close this one, I'm taking a new hit at this

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