-
Notifications
You must be signed in to change notification settings - Fork 113
Plugin doesn't work with sbt 1.3.0-RC1 #178
Comments
This might have already been fixed in master in #163. I'll have to check and make a new release. |
Turns out, the immediate issue in sbt/sbt#4688 is already fixed in master but other incompatibilities still prevent sbt-dependency-graph from working correctly. I'll try to track them down and file issues in sbt, let's hope they can be fixed before 1.3.0 is released. |
thanks @jrudolph for looking into it, appreciate it |
To set expectations, I don't have time to debug the behavior changes in sbt 1.3. From my current point, there's nothing to fix in sbt-dependency-graph master at this point. I could make a new release to get rid of the exception but the results would still be inaccurate in sbt.1.3.0-RC1 so I'm going to delay any further work here until the compatibility story of sbt 1.3 has been clarified. |
can we make a new release that gets rid of internal sbt api usage? |
@jrudolph i've tested the basic commands Can we make a new release from the code on master? version |
Released 0.10.0-RC1 which doesn't crash but the above sbt issues are still open and not completely resolved with sbt 0.13.0-RC3. |
thanks a ton! |
I'm kind of surprised that this functionality doesn't exist natively in SBT. Are there major obstacles to just merging it in? (which could hopefully help resolve some of the uses-internal-api nags) |
I've not followed sbt-dependency-graph's development closely, but from afar it seems to have stabilised. So, yes, I'd say it should be merged into sbt/sbt. |
See also coursier/coursier#1375 |
Fixes coursier/coursier#1375 Ref sbt/sbt#4706 / sbt/sbt#4688 Ref sbt/sbt-dependency-graph#178 Currently the UpdateReport returned by Coursier is missing callers from the direct dependencies. This is evident from the fact that `thisModule`'s information is not passed. Another missing information in the UpdateReport is ModuleReport that originates from subproject dependencies (aka inter-project dependencies). These two missing info result in broken rendering for sbt-dependency-graph. This commit attemps to fix them by passing them through to SbtUpdateReport. See the scripted test for confirmation.
Fixes coursier/coursier#1375 Ref sbt/sbt#4706 / sbt/sbt#4688 Ref sbt/sbt-dependency-graph#178 Currently the UpdateReport returned by Coursier is missing callers from the direct dependencies. This is evident from the fact that `thisModule`'s information is not passed. Another missing information in the UpdateReport is ModuleReport that originates from subproject dependencies (aka inter-project dependencies). These two missing info result in broken rendering for sbt-dependency-graph. This commit attemps to fix them by passing them through to SbtUpdateReport. See the scripted test for confirmation.
With sbt1.3.4, sbt support seems to have been completed. |
@nhiguchi It does compile with sbt-1.3.4, but there are few scripted failures that need careful audit and fixes. Someone with expertise in dependency management can submit a PR to resolve these |
Interesting, I didn't yet get to check those remaining failures. Hopefully,
I find time soon.
Anil Kumar Myla <[email protected]> schrieb am Di., 10. Dez. 2019,
15:10:
… @nhiguchi <https://github.com/nhiguchi> It does compile with sbt-1.3.4,
but there are few scripted failures that need careful audit and fixes.
Someone with expertise in dependency management can submit a PR to resolve
these
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#178>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAACNDFQFENON5QNMDTWAHDQX6PPHANCNFSM4HNXRYDA>
.
|
It leads to
When I try to add it to a Hello World project. |
That's weird. sbt-compat 1.2.6 is at https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.dwijnand/sbt-compat/scala_2.12/sbt_1.0/1.2.6/jars/, like it always has been. Either it's not looking in the sbt-plugin-releases repo, or it's lost the scala version (2.12) / sbt version (1.0) parts? The string output is ambiguous. |
I got the same error when i added the the plugin the a .sbt file in the wrong location (.sbt/1.0/plugins.sbt instead of .sbt/1.0/plugins/plugins.sbt) |
it's certainly not a full substitute, but I'm adjusting somewhat to life without sbt-dependency-graph by using |
Any progress in getting |
There is version 0.10.0-RC1 which works with sbt v1.3, it does the job for us |
does anyone know what the remaining issues are, then? why is this ticket still open? perhaps it should be closed and replaced with one or more tickets documenting any remaining problems? |
Had a look around, seems like sbt/sbt#4707 is still open. I'll try to confirm the issue myself today. Personally I've been using 1.3.10+ with RC1 with no issues (though I don't use stuff like withMissingOk) |
and with 115 thumbs 😆 😱 |
Here's my PR to fix it - sbt/sbt#5634 |
Thanks a lot for tackling that, @eed3si9n 👍 The main problem is that there are a few failing tests that point to other differences in reported data. In general, there are too few tests to be sure currently. To say the plugin works with 1.3.x would mean writing and validating a bigger test suite, etc. E.g. For family reasons, I didn't have the time or energy in the last year to dig into these issues. With all the added unknowns and restrictions of current times, this won't change in the near future. I'm sorry that I let myself become the bottleneck of any progress here. It's also unfortunate that this biggest change in recent sbt history happened during a time where I cannot react in time (wow, a year has already passed since this issue was filed). But since I cannot currently change the situation, the best would probably be to give the project in new hands. @jatcwang approached me a while ago and offered help which was much appreciated but also somewhat futile since, with me mostly out of the picture, there was no one else to coordinate with. I guess the easiest way to get me out of the picture would be fork or migrate the project to the WDYT? |
@jrudolph thanks a lot for all the work you've done already :) As you said I didn't really do much except triaging some issues and it'll having this under the sbt org umbrella will be great 👍 Seems like there are some interest in getting this into core sbt too. I think there are a few UX improvements I'd like to add before we stabilize (e.g. around tracking down where evicted deps are coming from) so having someone to collaborate with and review PRs will help |
If you're comfortable with it, moving this (IMO) essential plugin to the sbt org would be a positive step in the right direction. I think if you add me or Eugene as admins of the repo we can transfer it into the sbt org. I don't think it's worth the breaking change of changing groupId and package name. I think it's best to keep those things as is, and see if it can be merged into sbt/sbt. |
@jrudolph Thanks for all your work. I've be happy to help transition sbt-dependency-graph to sbt organization, and bring the code base into sbt/sbt. |
The dependency graph plugin is by far the most useful SBT plugin out there, and it should really be part of the SBT itself. |
Thanks for the support, @jatcwang, @dwijnand, @eed3si9n (and sorry for yet another delay).
I sent invites, though not sure if anyone else than the owner can transfer a repository, let me know if I need to do it, in that case, I need enough permission in the sbt organization to create a repo there.
I'd be fine with that as a temporary solution if the goal is to move the functionality into sbt/sbt. If that cannot be done in a reasonable time frame (e.g. a year), I'd prefer the project to change the groupId, so the project can move out of my namespace. Thanks also to everyone adding positive reactions here, that means a lot :) |
Could you give me the admin right or transfer it to eed3si9n/sbt-dependency-graph? I don't see Settings tab currently to initiate the transfer. |
Hi all and thanks for such useful plugin. With so many kind words already written I can only add a simple big Thank you to @jrudolph. Can someone clarify what is the current status of this issue? I didn't see any error for I read the comment:
What is not resolved? Would be good to clarify this. |
It's basically still unknown. Lots of stuff works like |
I toned down the note in the README to avoid further confusion. |
Just a note, there is already 1.4.0 in beta: http://eed3si9n.com/sbt-1.4.0-beta |
Ref sbt/sbt-dependency-graph#178 This in-sources sbt-dependency-graph.
I just in-sourced sbt-dependency-graph in sbt/sbt#5880, so I'm closing this issue. |
Original issue filed at sbt/sbt#4688
This plugin seems to use sbt's internal APIs which are no longer exposed in 1.3.x series. This issue is to fix the same
The text was updated successfully, but these errors were encountered: