-
Notifications
You must be signed in to change notification settings - Fork 278
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
Keep all maven deps in the central place for easier version management #1113
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, this looks really good and a change in a direction I really love to see, thank you so much!
I've left a comment regarding some implementation details on the scrooge side. Don't really mind breaking changes, as long as we can keep the functionality described in some form.
Let me know if I can help any more!
twitter_scrooge/twitter_scrooge.bzl
Outdated
scrooge_generator = None, | ||
util_core = None, | ||
util_logging = None): | ||
overriden_artifacts = {}): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand this change correctly, this will work if what we want is to resolve a different version of the artifacts.
However, our use case (and the main reason we implemented the overrides) was that we want to replace them with source-targets, not artifacts, and avoid the resolve.
I think we could achieve that by modifying the for_artifact_ids
list before passing it to repositories
, removing everything that we give a target for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blorente Do you want to keep using override approach, or would you consider moving dependencies to a toolchain? I have a branch for scrooge already, but I will make a PR after other toolchains PRs will progress: https://github.com/liucijus/rules_scala/tree/scrooge-toolchain
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving to a toolchain would be great, as long as we keep avoiding the resolution for targets that we override.
We'd be happy to migrate to toolchains, looking forward to that PR, we can discuss the specifics there :)
I guess, if this PR lands before the scrooge toolchains PR, we would be blocked on upgrading rules_scala
until the scrooge toolchains PR lands, but I think that is not a big problem :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope to get with the toolchain first, otherwise I will leave previous interface
build still fails |
licenses = ["notice"], | ||
server_urls = maven_servers, | ||
def junit_repositories( | ||
maven_servers = _default_maven_server_urls(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maven_servers
is not passed to repositories
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching, @simuons!
extra_jar_version = scala_version_extra_jars["com_geirsson_metaconfig_typesafe_config"]["version"], | ||
), | ||
artifact_sha256 = scala_version_extra_jars["com_geirsson_metaconfig_typesafe_config"]["sha256"], | ||
maven_servers = _default_maven_server_urls(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think maven_servers
should be taken from prams of scalafmt_repositories
|
||
def scala_proto_default_repositories( | ||
scala_version = _default_scala_version(), | ||
maven_servers = _default_maven_server_urls()): | ||
maven_servers = _default_maven_server_urls(), | ||
overriden_artifacts = {}): | ||
major_version = _extract_major_version(scala_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think major_version
is not passed to repositories
specs2/specs2.bzl
Outdated
|
||
def specs2_version(): | ||
return "4.4.1" | ||
|
||
def specs2_repositories( | ||
scala_version = _default_scala_version(), | ||
maven_servers = _default_maven_server_urls()): | ||
maven_servers = _default_maven_server_urls(), | ||
overriden_artifacts = {}): | ||
major_version = _extract_major_version(scala_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this major_version = _extract_major_version(scala_version)
could be in repositories
function? It would be possible to remove this duplicated line from other *_repositories
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very good Vaidas!! I think once this is merged we should prioritize creating a base list and have some sort of tool that will generate those files automatically for all scala flavors.
"2.12": _artifacts_2_12, | ||
} | ||
|
||
def repositories( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name repositories does not sound right, maybe I'm wrong. Let's continue reading and see
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand why you chose repositories... To keep current naming convention - but maybe it's an opportunity to name it better? define_maven_external_dependencies
or something similar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer shorter names, I think finding specific names with underscores is harder for users. I think name that includes repositories
is right as it aligns with its only usecase repository bzl pattern. I don't expect any other usecases.
licenses = ["notice"], | ||
server_urls = maven_servers, | ||
scala_version = scala_version, | ||
maven_servers = maven_servers, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're using the default servers all the time - why can't it be just the default value and skip the explicit parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Users may provide other server urls
def repositories( | ||
scala_version = default_scala_version(), | ||
for_artifact_ids = [], | ||
maven_servers = default_maven_server_urls(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see you already call here for default value - so can we remove the explicit parameter from caller site?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Users will need to be able to provide their own urls
@@ -0,0 +1,416 @@ | |||
artifacts = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!! How did you create this list? Did you use some kind of generator?
What happens when the next dev wants to update something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently it's a manual procedure to update deps
8cad240
to
70d00c6
Compare
…l, to address dep analyzer tests
70d00c6
to
bef58ac
Compare
@liucijus Looks good to me, thanks for putting so much thought into scrooge! |
bazelbuild#1113) * Move external artifact versions and shas to central place per Scala version * Move scalafmt deps to repositories * Move jmh deps to repositories * Move junit deps to repositories * Move specs2 deps to repositories * Move specs2-junit deps to repositories * Move proto deps to repositories * Move tut deps to repositories * Move scrooge deps to repositories * Move WORKSPACE test deps to repositories files * Move dep back to workspace to explicitly use jvm_maven_import_external, to address dep analyzer tests * Fix Scala version tests * Use repository deps for scrooge * Add scrooge version tests back * Keep current twitter scrooge repository interface
I've been thinking how to make external maven deps management simpler and decided to move all maven deps into single location per Scala version. I hope this will bring better visibility on which deps we are using and help update them more routinely.
My hope is that this refactoring helps towards:
This is a breaking change for some repository users (eg. scrooge). It's also not fully tested yet, marking PR as a draft and calling for your opinions.