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

Handling multimodule dependencies with shared version #1119

Closed
prolativ opened this issue Jun 20, 2022 · 2 comments
Closed

Handling multimodule dependencies with shared version #1119

prolativ opened this issue Jun 20, 2022 · 2 comments

Comments

@prolativ
Copy link

prolativ commented Jun 20, 2022

Is your feature request related to a problem? Please describe.
Some libraries split their functionality into multiple modules distributed as separate artifacts so that their users can depend only on the artifacts they really need. One inconvenient thing from the users' perspective here is that the version of each module needs to be specified separately even though in most cases they need to be kept in synch, e.g.

using lib "org.foo::foo-abc:1.2.3"
using lib "org.foo::foo-def:1.2.3"
using lib "org.foo::foo-ghi:1.2.3"

Describe the solution you'd like
We could introduce some way of specifying a dependency on multiple modules of the same library without duplicating the version. Some possibilities:

  1. Specify multiple modules in the same dependency string of a using directive, e.g.
using lib "org.foo::{foo-abc, foo-def, foo-ghi}:1.2.3"
  1. Specify multiple modules in the same using directive with a more explicit nested structure, e.g.
using lib:
  org "org.foo"
  artifacts "foo-abc", "foo-def", "foo-ghi"
  version "1.2.3"
  1. Specify the version of a library just once and then try to infer the versions of the remaining modules, e.g.
using lib "org.foo::foo-abc:1.2.3"
using lib "org.foo::foo-def"
using lib "org.foo::foo-ghi"

This might be tricky however because different artifacts coming from the same organization don't have to be different modules of the same library.

  1. Allow defining constant values inside using directives and referring to them in other directives, e.g.
using value "fooVersion" "1.2.3"
using lib "org.foo::foo-abc:${fooVersion}"
using lib "org.foo::foo-def:${fooVersion}"
using lib "org.foo::foo-ghi:${fooVersion}"

This solution seems both most powerful and most complicated to implement as we would need a new mechanism for defining and substituting constants. To simplify this some restrictions could be added, e.g.:

  • a constant has to be defined in the same file where it's referenced
  • a constant has to be defined before it's referenced (when parsing top-down and left to right).
    Also this would potentially clash with the proposed syntax for resolving paths Explicit handling of paths in using directives #1098
  1. Rely on tooling support, e.g. when a user changes the version of one module, provide a code action for changing the versions of the remaining ones. Here, however, we have similar problems to those from 3)
@tabdulradi
Copy link

I vote for syntax 1
using lib "org.foo::{foo-abc, foo-def, foo-ghi}:1.2.3"

@tgodzik
Copy link
Member

tgodzik commented Aug 16, 2023

Thanks for reporting the issues, based on the examples showed, I don't think there is a sensible solution and is out of scope for Scala CLI especially with the simplified using directives.

@tgodzik tgodzik closed this as completed Aug 16, 2023
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

No branches or pull requests

3 participants