Let prepareOffline accept a all flag
#1591
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lefou
force-pushed
the
prepare-offline
branch
3 times, most recently
from
8f4d232
to
6e3181b
Compare
lefou
added
the
compat-breaker
|
Any opinion about the solution and the incompatible change? @lolgab |
This should support more fine-control in inheriting modules. Also, fetch only essential dependency in Java and Scala module, and keep the full fetch behint hints: all, source, ...
lefou
force-pushed
the
prepare-offline
branch
from
6e3181b
to
0cdd2ac
Compare
lihaoyi
reviewed
Dec 9, 2021
|
Maybe, a cleaner but less flexible approach would be to just add a boolean |
|
Then, it's up to the those modules with special needs to provide additional targets |
|
Yeah I suppose it depends on how much flexibility we expect to need; either a small set of flags if we don't expect to need to add much more, or the |
lefou
changed the title
all flag parameter
lefou
changed the title
all flag parameterall flag
|
@lihaoyi I changed the implementation to accept a simple |
lihaoyi
approved these changes
Dec 10, 2021
pbuszka
pushed a commit
to pbuszka/mill
that referenced
this pull request
Dec 26, 2021
This should support more control in inheriting modules. Also, fetch only essential dependencies in Java and Scala modules, and keep the full fetch behind an `all` flag, which can be set as parameter. This is a binary-incompatible change and I have no idea how to preserve compatibility. Although I could keep the old signature and just forward to the newer, Loading plugins that also inherit older `OfflineSupportModule`s seem to fail nevertheless. Also I think Mill isn't checking for multiple commands with the same name, so I fear just because it works on my machine, it may still lead to some failures for others. Only fix would be to invent a new name for the command (and deprecate the old). As Mill 0.10.x is binary-incompatible anyways, I think this one should be ok. Pull request: com-lihaoyi#1591
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should support more control in inheriting modules.
Also, fetch only essential dependencies in Java and Scala modules,
and keep the full fetch behind a
allflag, which can be set as parameter.This is a binary-incompatible change and I have no idea how to preserve compatibility.
Although I could keep the old signature and just forward to the newer,
Loading plugins that also inherit older
OfflineSupportModules seem to fail nevertheless.Also I think Mill isn't checking for multiple commands with the same name,
so I fear just because it works on my machine, it may still lead to some failures for others.
Only fix would be to invent a new name for the command (and deprecate the old).
As Mill 0.10.x is binary-incompatible anyways, I think this one should be ok.
Fix #1576