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

Update bzlmod dependencies and enhance separation of components #257

Merged
merged 10 commits into from
Sep 5, 2022

Conversation

avdv
Copy link
Member

@avdv avdv commented Aug 5, 2022

This PR takes bzlmod migration a step further and tries to lay ground for future work in that area.

Currently, there are a few components / modules which were all depending on each other:

  • core
  • toolchains:
    • cc
    • go
    • java
    • posix
    • rust
    • python
  • nixpkgs (the everything component)

It should be possible to require a specific toolchain with only pulling in the required dependencies.

This PR adds a toolchains parameter to the rules_nixpkgs_dependencies function signalling which toolchain is required.

Interestingly, every component depends on java, posix and the cc toolchain (even the core). This is because of the stardoc dependency which consists of a java_binary...

IMO, it would be a good idea to separate the docs generation into another component, in order to get rid of the excess dependencies. WDYT?

`rules_go` is available on the central registry now. So add it and update
http_archive references to version 0.33.0 to match the bzlmod version.
This enables every module to pass in the required toolchains explicitly.
... instead of `io_tweag_rules_nixpkgs`.
This is needed since the java toolchain is loaded using `@rules_nixpkgs_java` in
`core/docs/dependencies_2.bzl` which is loaded in the WORKSPACE for every toolchain - including
the java toolchain, where it must refer to itself.
@aherrmann
Copy link
Member

IMO, it would be a good idea to separate the docs generation into another component, in order to get rid of the excess dependencies. WDYT?

That sounds like a reasonable approach to me, if feasible. FWIW modules also introduce a notion of dev-dependencies, so, perhaps in that case the components needed for Stardoc could simply be marked as such and wouldn't be needed for regular use. cc @fricklerhandwerk any thoughts? I think you're more familiar with this part than me.

Copy link
Member

@aherrmann aherrmann left a comment

Choose a reason for hiding this comment

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

Thank you for looking into this! Looks good, only a question about dev-dependencies.

core/MODULE.bazel Outdated Show resolved Hide resolved
nixpkgs/repositories.bzl Outdated Show resolved Hide resolved
nixpkgs/repositories.bzl Show resolved Hide resolved
Copy link
Member

@aherrmann aherrmann left a comment

Choose a reason for hiding this comment

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

Thanks for the updates, that looks good!

IMO, it would be a good idea to separate the docs generation into another component, in order to get rid of the excess dependencies. WDYT?

Is this something you want to tackle in a follow-up PR?

@avdv
Copy link
Member Author

avdv commented Sep 5, 2022

Is this something you want to tackle in a follow-up PR?

Yes, I created an issue to track this: #264

@avdv avdv added the merge-queue merge on green CI label Sep 5, 2022
@mergify mergify bot merged commit b942c09 into master Sep 5, 2022
@mergify mergify bot deleted the bzlmod-updates branch September 5, 2022 14:03
@mergify mergify bot removed the merge-queue merge on green CI label Sep 5, 2022
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.

3 participants