Merge DottyPlugin in sbt

The sbt-dotty plugin sources can be found here: https://github.com/lampepfl/dotty/tree/master/sbt-dotty/src/dotty/tools/sbtplugin
It is composed of two independent parts:

DottyIDEPlugin: install and configure vscode Dotty extension, start vscode
DottyPlugin: manage Scala instance for Scala 3, configure compile and doc

This issue is scoped to merging the DottyPlugin logic into sbt. The DottyIDEPlugin will not be merged.
I give below a detailed description of the plugin and I propose an equivalent implementation in sbt.
Most of the time, the logic can be moved to either the default setting value or to the upstream libraries (librarymanagement, zinc).
Description
Scala 3 Instances

Key
Explanation
Proposed Implementation

isDotty
new boolean setting
There already is ScalaInstance.isDotty in sbt but the setting is easier to use and it will be very useful during the migration to Scala 3. isDotty will be renamed isScala3

managedScalaInstance
false if isDotty.The Scala instances are fetched by sbt-dotty
Should remain true. sbt will manage Scala 3 instances

scalaInstance
Call dependencyResolution.value.update to fetch the Scala 3 compiler and library, as well as the Scala 2.13 library
Update ScalaArtifacts in librarymanagement to manage Scala 3 artifacts.Should we support Dotty versions (0.xxx)?

libraryDependencies
Add the scala3-library dependency.
Update Defaults.autoLibraryDependency to add scala3-library instead of scala-library(I guess scala-library_2.13 is added transitively by the scala3-library dependency)

scalaBinaryVersion
Add some logic for RC versions:The binary version of 0.27.0-RC1 is 0.27The binary version of 3.0.0-M1-bin-20201027-b5a1715-NIGHTLY is 3.0.0-M1
Update the default scalaBinaryVersion logic if necessary.(Will have RC versions after for 3.0.0?)

Zinc Config

Key
Explanation
Proposed Implementation

incOptions
Add a TastyFileManager as an external hook of the incOptions so that the .tasty files are pruned
Handle in Zinc

scalaCompilerBridgeBinaryJar
Call dependencyResolution.value.update to fetch the sbt-bridge jars.
Merge sbt-bridge in Zinc.Update ZincComponentCompiler.getDefaultBridgeModule.

Compiler classpath and bootclasspath
Quoting sbt-dotty comment:

We want:

Nothing but the Java standard library on the JVM bootclasspath (starting with Java 9 we cannot inspect it so we don't have a choice)

scala-library, dotty-library, dotty-compiler and its dependencies on the _JVM_classpath, because we need all of those to actually run the compiler.
NOTE: All of those should have the same version (equal to scalaVersion for everything but scala-library). (Complication: because dottydoc is a separate artifact with its own dependencies, running it requires putting extra dependencies on the JVM classpath)

scala-library, dotty-library on the compiler bootclasspath or classpath (the only difference between them is that the compiler bootclasspath has higher priority, but that should never make a difference in a sane environment).
NOTE: the versions of {scala,dotty}-library used here do not necessarily match the one used in 2. because a dependency of the current project might require a more recent standard library version, this is OK
TODO: ... but if macros are used we might be forced to use the same versions in the JVM and compiler classpaths to avoid problems, this needs to be investigated.

every other dependency of the user project on the compiler classpath.

By default, zinc will put on the compiler bootclasspath the scala-library used on the JVM classpath, even if the current project transitively depends on a newer scala-library (this works because Scala 2 guarantees forward- and backward- binary compatibility, but we don't necessarily want to keep doing that in Scala 3).
So for the moment, let's just put nothing at all on the compiler bootclasspath, and instead let sbt dependency management choose which scala-library and dotty-library to put on the compiler classpath.
Maybe eventually we should just remove the compiler bootclasspath since it's a source of complication with only dubious benefits.

My understanding is that sbt-dotty is hacking the classpathOptions to prevent Zinc from adding the wrong scala-library-3.0 on the bootClasspath.
I propose to let the classpathOptions unchanged and add some logic in Zinc to resolve the correct scala library.

Key
Explanation
Proposed Implementation

classpathOptions
If isDotty then autoBoot and filterLibrary are set to false.
Do not change the classpathOptions.Instead Zinc should add the correct scala library

console / classpathOptions
The console / classpathOptions must not be affected by the above classpathOptions override.
Should not be needed

scalacOptions
If isDotty and Java 8, the compiler bootclasspath must contain the JVM bootclasspathto prevent Zinc from breaking.
Handle in Zinc

scalaModuleInfo
If isDotty it deactivates the override of scala-library and scala-compiler versions.
Backport to the default scalaModuleInfo:overrideScalaVersion = isScala3.value

doc task

Key
Explanation
Proposed Implementaion

useScala3doc
New boolean setting to use the new scala3doc rather than dotty-doc.Default to false.
Will scala3doc become the only doc tool for Scala 3?If so this setting will not be added.

resolvers
If useScala3doc add the jcenterRepo
Will scala3doc be published to Maven Central?If so this is not needed.

scala3docOptions
New Seq[String] setting
I dont think we need a new setting for this:We can use doc / scalacOptions instead

Compile / doc / scalacOptions
If useScala3doc add scala3docOptions with the "--+DOC+" prefix There are a few questions that remain.
The "--+DOC+" prefix could be added by a utility method:Compile / doc / scalacOptions ++= Seq("-foo", "-bar").map(_.withDocPrefix)

doc / scalaInstance
Depending on isDotty and useScala3doc it loads scala3doc, dotty-doc or the default doc / scalaInstance
When scala3doc replace dotty-doc then backport the logic to the default doc / scalaInstance

<Compile | Test> / doc / sources
If isDotty then compile and add the .tasty files
Backport the logic to the default doc / sources in configSettings

<Compile | Test> / doc / scalacOptions
If isDotty add "-project ${name.value}" and "-from-tasty"
Backport the logic to the default doc / sources in configSettings

withDottyCompat
Quoting sbt-dotty comment:

If this ModuleID cross-version is a Dotty version, replace it by the Scala 2.x version that the Dotty version is retro-compatible with, otherwise do nothing.
This setting is useful when your build contains dependencies that have only been published with Scala 2.x, if you have:
libraryDependencies += "a" %% "b" % "c"

you can replace it by:
libraryDependencies += ("a" %% "b" % "c").withDottyCompat(scalaVersion.value)

This will have no effect when compiling with Scala 2.x, but when compiling with Dotty this will change the cross-version to a Scala 2.x one.
This works because Dotty is currently retro-compatible with Scala 2.x.
NOTE: As a special-case, the cross-version of scala3-library and scala3-compiler
will never be rewritten because we know that they're Scala 3 only.
This makes it possible to do something like:
libraryDependencies ~= (_.map(_.withDottyCompat(scalaVersion.value)))

withDottyCompat only deals with Scala 3 module depending on Scala 2.13 artifact. This was, so far, the only useful pattern of cross binary compatibility.
But we can believe that such patterns will diversified. For instance, it will  soon be possible to have a dependency to a Scala 3 artifact in a Scala 2.13.4 module.
So I propose to generalize withDottyCompat with the following:
def withCompat(mapping: (String, String)*): ModuleID

so that we can do
libraryDependencies += ("a" %% "b" % "c").withCompat("x" -> "y")

meaning that if the current binary version is "x" we used "y" instead.
The special-case described above won't be supported which is okay since it will be less and less useful.
Scala-js
The Scala.js specific logic will not be merged into sbt.
Instead it is moved to sbt-scalajs (https://github.com/scala-js/scala-js/pull/4280).
Roadmap
1. Merge sbt-bridge in Zinc

Update ZincComponentCompiler.getDefaultBridgeModule

2. Configure the compiler bootClasspath in Zinc
3. Add TastyFileManager logic in Zinc
4. Manage Scala 3 instances:

Add isScala3 setting
Update ScalaArtifacts in librarymanagement
Update Defaults.autoLibraryDependency
Update scalaBinaryVersion if necessary

5. Add withCompat in librarymanagement
6. Add support for scala3doc:

Update the doc / scalaInstance
Update the doc / sources
Update the doc / scalacOptions

Unsettled questions
A few questions on which I would like to have someone else's opinion.
1. Should we support Dotty versions (0.xxx)?
Pros:

As of today, library authors want to be compatible with both 0.27.0 and 3.0.0-M1 (see blogpost)

Cons:

Will soon be unecessary complexity: Dotty versions won't be used anymore
sbt-dotty can still be used to handle Dotty versions

IMO sbt should not support 0.27.0 and earlier versions.
@sjrd, @eed3si9n and others: What is your opinion?
2. Does it work to have the scala-library and scala3-library on the compiler bootclasspath?
I guess yes and I also think it is easier given that sbt does it this way for Scala 2.
@smarter Do you confirm?
3. Will scala3doc become the only doc tool for Scala 3? Will it be published to Maven Central?
@abgruszecki Can you answer these questions?
4. Do you agree with the generalization of withDottyCompat as described above?
@sjrd, @eed3si9n, @smarter what do you think?

isDotty

I think we should stop using the name "dotty" outside of the compiler internals, so if we keep it, it should be isScala3, but now that we're using >= 3 version numbers, this could also be replaced by something like VersionNumber(scalaVersion.value).matchesSemVer(SemanticSelector(">= 3.0.0-M1")) using https://www.scala-sbt.org/1.x/docs/sbt-1.2-Release-Notes.html#Semantic+Version+selector+API which is longer but more flexible.

Should we support Dotty versions (0.xxx)?

No need, people can keep sbt-dotty while they keep using old dotty versions.

Update the default scalaBinaryVersion logic if necessary.

The exact thing to do here will be determined by https://github.com/lampepfl/dotty/issues/10244

My understanding is that sbt-dotty is hacking the classpathOptions to prevent Zinc from adding the wrong scala-library-3.0 on the bootClasspath.

So this used to be the case but I think it should work correctly as of recent zinc versions as I added support for passing multiple library jars to ScalaInstance, the remaining reason for customizing this stuff was an attempt at allowing a project to set its scalaVersion to 3.0.0 but to use the standard library from Scala 3.0.1 if it transitively depends on it, but this won't be needed if we preserver backward and forward binary compatibility in the 3.0.x time frame which seems to be where we're headed in https://github.com/lampepfl/dotty/issues/10244

Will scala3doc become the only doc tool for Scala 3?

Yes.

Will scala3doc be published to Maven Central?

https://github.com/lampepfl/scala3doc/issues/226

libraryDependencies += ("a" %% "b" % "c").withCompat("x" -> "y")

I don't know what the right API is here but I think that one is too easy to misuse, there's only two compatibility modes we have currently (2.13 to 3 and 3 to 2.13), so we shouldn't accept arbitrary inputs, maybe withCompat could take an enum instead?

Should we support Dotty versions (0.xxx)?

+1 on dropping 0.27.0 support.

Do you agree with the generalization of withDottyCompat as described above?

In https://github.com/lampepfl/dotty/pull/9974#discussion_r502463586 @julienrf had a good insight that we already have cross that does ModuleID conversion. In other words, we could come up with some cross(...) rules that would change the interpretation of %. https://www.scala-sbt.org/1.x/docs/Cross-Build.html#More+about+using+cross-built+libraries

This uses a custom function to determine the Scala version to use based on the binary Scala version:

("a" % "b" % "1.0") cross CrossVersion.binaryMapped {
  case "2.10" => "2.10.0" // useful if a%b was released with the old style
  case x => x
}

I wonder if we could do something like:
("a" % "b" % "1.0").cross(CrossVersion.for3_use2_13)

// equivalent to
("a" % "b" % "1.0") cross CrossVersion.binaryMapped {
  case "3.0" => "2.13" // use _2.13 only for Scala 3.0
  case x => x
}

I agree with everything that was said.
For withDottyCompat, we should definitely stick to something that is limited to "use 2.13 for 3" and "use 3 for 2.13". @eed3si9n's proposal seems reasonable.

Reg. Scala3doc: in The End, we should:

not need useScala3doc as there will be only one doctool for Scala3

not need to add resolvers as the dependencies of Scala3doc should be published to Maven Central

not need to add the magick prefix to Scala3doc-specific options

and 3) need updates upstream in Scala3doc, though. In particular reg. 3), right now the magick prefix should only be added to Scala3doc-specific options, which is the reason why for the time being we have a separate setting key for these options.

What's the timeline for these changes in SBT? As long as we only do them after Scala3doc was updated, we're golden in this particular area.

What's the timeline for these changes in SBT?

If we want sbt 1.5.0 to be out definitely by February, 2021, I think we should aim for RC-1 by Christmas, 2020.

I don't fully get the sbt versioning policy, but couldn't these changes go into a 1.4.x release?

If there is at least one new public member anywhere, such as a setting, it won't be forward binary compatible, and that means 1.5.0.

but sbt sometimes introduces new settings in patch versions, e.g. https://github.com/sbt/sbt/releases/tag/v1.3.2 says:

Adds a new setting called includePluginResolvers (default false).

We don't really new to add new public members:

isScala3 and withCompat can be delayed to 1.5
we can advocate for alternative solutions: matchesSemVer, binaryMapped
the new implementation could be compatible with sbt-dotty (maybe not the TastyFileManager though)

So technically it can be shipped into 1.4.x.
However, if we ship it in 1.5.0 we will have RC versions to test it and we will eventually be more confident.

However, if we ship it in 1.5.0 we will have RC versions to test it and we will eventually be more confident.

Yea it's that basically. Whether something 1.4.x or 1.5.0 is determined more by whether it's likely to break the existing build.
New features tend to include regressions, so we put them in 1.X.0 so we can go through release candidates. I'd be happy to release M1, M2 etc as soon as it merges in addition.

Should we auto add "-Ytasty-reader" option if sandwich?
https://github.com/sbt/sbt/pull/6121

No, the point of making it a flag is that it's experimental so we want people to set it explicitly if they want to try it

One thing that isn't handled by sbt-dotty but should be handled once dotty support is integrated in sbt: the semanticdbEnabled setting which is built into sbt (for dotty, this should just enable the -Ysemanticdb flag)

@smarter that is already handled by sbt

About the classpath configuration @smarter said

So this used to be the case but I think it should work correctly as of recent zinc versions as I added support for passing multiple library jars to ScalaInstance, the remaining reason for customizing this stuff was an attempt at allowing a project to set its scalaVersion to 3.0.0 but to use the standard library from Scala 3.0.1 if it transitively depends on it, but this won't be needed if we preserver backward and forward binary compatibility in the 3.0.x time frame which seems to be where we're headed in lampepfl/dotty#10244

I confirm that the default -bootclasspath and -classpath configuration is working well with Scala 3.
The -bootclasspath option contains:

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>/home/piquerez/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala3-library_3.0.0-M1/3.0.0-M1/scala3-library_3.0.0-M1-3.0.0-M1.jar
/home/piquerez/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.3/scala-library-2.13.3.jar

And -classpath contains (I don't have any dependencies):

/example/target/scala-3.0.0-M1/classes

I share with you a status of my progress on this task:

[x] Scala 3 instance class loader
Unlike the Scala 2 instance, the Scala 3 instance needs the org.scala-sbt:compiler-interface in its class loader.
It has been added in sbt-dotty for compatibility with sbt 1.3.x and 1.4.x
It has been added by default for all Scala instances in https://github.com/sbt/sbt/pull/6199 (sbt 1.5.x)
Also it has been added in Mill (https://github.com/lihaoyi/mill/pull/1019)
[x] Scala 3 compiler bridge
The Scala 3 compiler bridge has been upgraded to Zinc 1.4.3 in https://github.com/lampepfl/dotty/pull/10607
It still provides an implementation of the old interface for compatibility with sbt 1.3.x and Mill. Once Mill has upgraded to Zinc 1.4.3 we will be able to remove the old xsbt.CompilerInterface implementation.
[x] Add TastyFileManager logic in Zinc: https://github.com/sbt/zinc/pull/956
[ ] Manage Scala 3 compiler instance in sbt: I start working on that today
[ ] Manage Scala 3 doc instance in sbt

I think we should stop using the name "dotty" outside of the compiler internals, so if we keep it, it should be isScala3, but now that we're using >= 3 version numbers, this could also be replaced by something like VersionNumber(scalaVersion.value).matchesSemVer(SemanticSelector(">= 3.0.0-M1")) using https://www.scala-sbt.org/1.x/docs/sbt-1.2-Release-Notes.html#Semantic+Version+selector+API which is longer but more flexible.

Also that could (IMO should) be made shorter (but I guess this is not the place to get into details)

@eed3si9n
I need your opinion about the management of the scala3doc artifact.
In Scala 2, the doc compiler is provided by the scala-compiler artifact so we can reuse the <project> / scalaInstance in the doc task.
In Scala 3 the doc compiler is provided by a distinct scala3doc artifact. The <project> / scalaInstance does not contain it in sbt-dotty nor in #6206. That's why sbt-dotty creates a doc / scalaInstance by fetching scala3doc explicitly. That does the job. But it does not integrate very well with the tool configuration logic because scala3doc does not appear in allDependencies or in the  ivyModule.dependencies.
Alternatively I can simply add scala3doc in the ScalaArtifacts.toolDependencies method. It is a simple solution but it forces every Scala 3 project to fetch scala3doc even if they don't use the doc task.
What's your favorite solution?
1- Fetch scala3doc in doc / scalaInstance under the hood.
2- Add scala3doc in ScalaArtifacts.toolDependencies.
@smarter suggested that maybe we should stop using the tool configuration. I am not really convinced and if we go that way I would rather do it in a separate project.

@adpi2 Thanks for the ping. I think we need to explore what scala3doc is before we can made the decision.
In Scala 2 the doc compiler was part of the compiler, so we didn't have to worry about (additional) library dependencies.
Now Scala 3 will be based on Kotlin's documentation engine, Flexmark, and Jackson?! https://github.com/lampepfl/dotty/blob/854f58331b5ebd86ffb9326894a4870cb3ade5e7/project/Build.scala#L1548-L1560
          libraryDependencies ++= Seq(
            "org.jetbrains.dokka" % "dokka-core" % dokkaVersion,
            "org.jetbrains.dokka" % "dokka-base" % dokkaVersion,
            "org.jetbrains.kotlinx" % "kotlinx-html-jvm" % "0.7.2", // Needs update when dokka version changes
            "com.vladsch.flexmark" % "flexmark-all" % "0.42.12",
            "nl.big-o" % "liqp" % "0.6.7",
            "org.jsoup" % "jsoup" % "1.13.1", // Needed to process .html files for static site
            "args4j" % "args4j" % "2.33",
            Dependencies.`jackson-dataformat-yaml`,

            "org.jetbrains.dokka" % "dokka-test-api" % dokkaVersion % "test",
            "com.novocode" % "junit-interface" % "0.11" % "test",
          ),

The main motivation for using tool configuration is so the resolution goes through the normal library management channel (necessary since some companies would go out to the Internet via Artifactory etc) and to do the dependency resolution in a single shot.
I don't think it's bad to grab all the necessary JAR in the very first use of a Scala 3 version, but with this kitchen sink of additional dependencies, we probably need to be more careful about how ScalaInstance is used to set up the ClassLoader for regular compilation.

Okay so maybe we should use the same ScalaInstance for doc but we should also be able to distinguish between the loaderCompilerOnly, that does not contain the scala3doc and all its dependencies, and the loader that contains all the jars.
So adding an extra layer in the ScalaInstance class loader...
It would not make any difference for Scala 2 but it will give extra safety in Scala 3 for regular compilation.

Here's the current list of JARs after locally fixing the Dotty build since it's currently not hooked up to anything:
sbt:scala3> show scala3doc/Compile/externalDependencyClasspath
[info] * Attributed(.../https/jcenter.bintray.com/org/jetbrains/dokka/dokka-core/<IP_ADDRESS>/dokka-core-<IP_ADDRESS>.jar)
[info] * Attributed(.../https/jcenter.bintray.com/org/jetbrains/dokka/dokka-base/<IP_ADDRESS>/dokka-base-<IP_ADDRESS>.jar)
[info] * Attributed(.../https/jcenter.bintray.com/org/jetbrains/kotlinx/kotlinx-html-jvm/0.7.2/kotlinx-html-jvm-0.7.2.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-all/0.42.12/flexmark-all-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/nl/big-o/liqp/0.6.7/liqp-0.6.7.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jsoup/jsoup/1.13.1/jsoup-1.13.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/args4j/args4j/2.33/args4j-2.33.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/fasterxml/jackson/dataformat/jackson-dataformat-yaml/2.9.8/jackson-dataformat-yaml-2.9.8.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/scala-lang/modules/scala-asm/7.3.1-scala-1/scala-asm-7.3.1-scala-1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/scala-sbt/compiler-interface/1.3.5/compiler-interface-1.3.5.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jline/jline-reader/3.15.0/jline-reader-3.15.0.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jline/jline-terminal/3.15.0/jline-terminal-3.15.0.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jline/jline-terminal-jna/3.15.0/jline-terminal-jna-3.15.0.jar)
[info] * Attributed(.../https/jcenter.bintray.com/org/jetbrains/markdown/0.1.45/markdown-0.1.45.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib-jdk8/1.4.10/kotlin-stdlib-jdk8-1.4.10.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-reflect/1.4.10/kotlin-reflect-1.4.10.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-kotlin/2.11.1/jackson-module-kotlin-2.11.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/fasterxml/jackson/dataformat/jackson-dataformat-xml/2.11.1/jackson-dataformat-xml-2.11.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-coroutines-core-jvm/1.3.9/kotlinx-coroutines-core-jvm-1.3.9.jar)
[info] * Attributed(.../https/jcenter.bintray.com/org/jetbrains/dokka/dokka-analysis/<IP_ADDRESS>/dokka-analysis-<IP_ADDRESS>.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib/1.4.10/kotlin-stdlib-1.4.10.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib-common/1.4.10/kotlin-stdlib-common-1.4.10.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark/0.42.12/flexmark-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-abbreviation/0.42.12/flexmark-ext-abbreviation-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-admonition/0.42.12/flexmark-ext-admonition-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-anchorlink/0.42.12/flexmark-ext-anchorlink-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-aside/0.42.12/flexmark-ext-aside-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-attributes/0.42.12/flexmark-ext-attributes-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-autolink/0.42.12/flexmark-ext-autolink-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-definition/0.42.12/flexmark-ext-definition-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-emoji/0.42.12/flexmark-ext-emoji-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-enumerated-reference/0.42.12/flexmark-ext-enumerated-reference-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-escaped-character/0.42.12/flexmark-ext-escaped-character-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-footnotes/0.42.12/flexmark-ext-footnotes-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-gfm-issues/0.42.12/flexmark-ext-gfm-issues-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-gfm-strikethrough/0.42.12/flexmark-ext-gfm-strikethrough-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-gfm-tables/0.42.12/flexmark-ext-gfm-tables-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-gfm-tasklist/0.42.12/flexmark-ext-gfm-tasklist-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-gfm-users/0.42.12/flexmark-ext-gfm-users-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-gitlab/0.42.12/flexmark-ext-gitlab-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-jekyll-front-matter/0.42.12/flexmark-ext-jekyll-front-matter-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-jekyll-tag/0.42.12/flexmark-ext-jekyll-tag-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-media-tags/0.42.12/flexmark-ext-media-tags-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-macros/0.42.12/flexmark-ext-macros-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-ins/0.42.12/flexmark-ext-ins-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-xwiki-macros/0.42.12/flexmark-ext-xwiki-macros-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-superscript/0.42.12/flexmark-ext-superscript-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-tables/0.42.12/flexmark-ext-tables-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-toc/0.42.12/flexmark-ext-toc-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-typographic/0.42.12/flexmark-ext-typographic-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-wikilink/0.42.12/flexmark-ext-wikilink-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-yaml-front-matter/0.42.12/flexmark-ext-yaml-front-matter-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-ext-youtube-embedded/0.42.12/flexmark-ext-youtube-embedded-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-formatter/0.42.12/flexmark-formatter-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-html-parser/0.42.12/flexmark-html-parser-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-jira-converter/0.42.12/flexmark-jira-converter-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-pdf-converter/0.42.12/flexmark-pdf-converter-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-profile-pegdown/0.42.12/flexmark-profile-pegdown-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-util/0.42.12/flexmark-util-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/vladsch/flexmark/flexmark-youtrack-converter/0.42.12/flexmark-youtrack-converter-0.42.12.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/antlr/antlr/3.5.1/antlr-3.5.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.11.1/jackson-annotations-2.11.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.11.1/jackson-core-2.11.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.11.1/jackson-databind-2.11.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/yaml/snakeyaml/1.23/snakeyaml-1.23.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.4/scala-library-2.13.4.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/google/protobuf/protobuf-java/3.7.0/protobuf-java-3.7.0.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/scala-sbt/util-interface/1.3.0/util-interface-1.3.0.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/net/java/dev/jna/jna/5.3.1/jna-5.3.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib-jdk7/1.4.10/kotlin-stdlib-jdk7-1.4.10.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-jaxb-annotations/2.11.1/jackson-module-jaxb-annotations-2.11.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/codehaus/woodstox/stax2-api/4.2.1/stax2-api-4.2.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/fasterxml/woodstox/woodstox-core/6.2.1/woodstox-core-6.2.1.jar)
[info] * Attributed(.../https/jcenter.bintray.com/org/jetbrains/dokka/kotlin-analysis-intellij/<IP_ADDRESS>/kotlin-analysis-intellij-<IP_ADDRESS>.jar)
[info] * Attributed(.../https/jcenter.bintray.com/org/jetbrains/dokka/kotlin-analysis-compiler/<IP_ADDRESS>/kotlin-analysis-compiler-<IP_ADDRESS>.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/jetbrains/annotations/13.0/annotations-13.0.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/nibor/autolink/autolink/0.6.0/autolink-0.6.0.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/openhtmltopdf/openhtmltopdf-core/0.0.1-RC15/openhtmltopdf-core-0.0.1-RC15.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/openhtmltopdf/openhtmltopdf-pdfbox/0.0.1-RC15/openhtmltopdf-pdfbox-0.0.1-RC15.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/openhtmltopdf/openhtmltopdf-rtl-support/0.0.1-RC15/openhtmltopdf-rtl-support-0.0.1-RC15.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/openhtmltopdf/openhtmltopdf-jsoup-dom-converter/0.0.1-RC15/openhtmltopdf-jsoup-dom-converter-0.0.1-RC15.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/antlr/antlr-runtime/3.5.1/antlr-runtime-3.5.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/antlr/ST4/4.0.7/ST4-4.0.7.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/jakarta/xml/bind/jakarta.xml.bind-api/2.3.2/jakarta.xml.bind-api-2.3.2.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/jakarta/activation/jakarta.activation-api/1.2.1/jakarta.activation-api-1.2.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/apache/pdfbox/pdfbox/2.0.11/pdfbox-2.0.11.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/apache/pdfbox/xmpbox/2.0.11/xmpbox-2.0.11.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/de/rototor/pdfbox/graphics2d/0.15/graphics2d-0.15.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/com/ibm/icu/icu4j/59.1/icu4j-59.1.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/org/apache/pdfbox/fontbox/2.0.11/fontbox-2.0.11.jar)
[info] * Attributed(.../https/repo1.maven.org/maven2/commons-logging/commons-logging/1.2/commons-logging-1.2.jar)

@romanowski says the Kotlin dependency and likely be removed in the future?

Sorry for being late to the party :)
We would need 2-3 weeks to get rid of Kotlin deps if this is really necessary. We've started as a plugin for dokka but we gradually moving away into being a standalone thing and we would need to accelarate that process.
This leaves other dependencies that are core to the scala3doc:

flexmark: for dealing with markdown in API comments nad static pages)
liqp: for building static site
jsoup: for building static site (precisely to link to API pages from static site that may be defined in .html)
Jackson: we are using it for some things but we should be able to remove that if we really need

So we can clear some of our dependencies but it will be not possible to get it e.g. one external jar.

If it's meant to be a standalone app, rather than a library, then one way to at least minimize the download would be to turn it into a fat JAR?
I just suggested that also so we won't have JCenter artifacts - https://github.com/lampepfl/dotty/issues/10904

The more I think about the proper solution the more I see that compiler and doctool should have separated.
Scala3doc is loosely coupled with a compiler so compilation and doc may use different scalaVersion (or to be precise scalaVersion may be different than scala3doc one).
The only relation that we need to have with a compiler is using compatible version of TASTY. As long as we do not expose it as first class citizen in sbt we can keep same scalaVersion for both doc and compile

If it's meant to be a standalone app, rather than a library, then one way to at least minimize the download would be to turn it into a fat JAR?

I am not a big fan of fat jars so I see it as a last resort. We are planning to expose parts of scala3doc to allow extensions but we will turn those into API jars anyway.

I just suggested that also so we won't have JCenter artifacts - lampepfl/dotty#10904

Jcenter was needed for dokka but it was recently disted to maven central so we should be able to remove it.

The more I think about the proper solution the more I see that compiler and doctool should have separated.

When a new Scala versions comes out today, the user can say ++2.13.4! and cross build (including doc).
In the world where doctool is separated, do we basically use the same doctool throughout the 3.x lifecycle (ignoring 3.T) since TASTY compatibility would be maintained?

Scala3doc is loosely coupled with a compiler so compilation and doc may use different scalaVersion (or to be precise scalaVersion may be different than scala3doc one).

I don't think that's a good idea, the version of the compiler used by scala3doc needs to be as recent as the version used for compilation since minor releases (3.1, 3.2, ...) will bump the tasty minor version. And if sbt has two load two compiler instances then documentation generation will be slower since the JIT will have more work to do, and sbt will have to use more ram.

Currently every sbt release sets scalaVersion to the latest stable version, and then you can upgrade or downgrade it.  Sounds to me like scala3doc should work the same way.  Ideally every Scala 3 version carried with it the "latest and greatest" scala3doc version to use, rather than have that in sbt-dotty / sbt releases - but I can't think of any mechanism we have for that.  Optional dependencies of scala3-compiler?

Ideally every Scala 3 version carried with it the "latest and greatest" scala3doc version to use

The compiler and doctool are released together and use the same version number, there's no need for any complex matching of versions.

Jackson: we are using it for some things but we should be able to remove that if we really need

It looks like you're using it to parse yaml, but you're also using flexmark to do that, are both really needed?

So adding an extra layer in the ScalaInstance class loader...

I think that makes sense, I was also wondering if we should split the repl out of scala3-compiler in its own artifact (it depends on jline, and in the future it might also depend on coursier to provide ivy import like ammonite), to keep things simple I think we could add just one layer on top of the compiler layer for everything else, and we can put the doc-tool, repl and their dependencies in there.

From the entire list of dependenices of scala3doc there are still 2 artifacts that are not available in repo1.maven.org:
[error] (root / update) sbt.librarymanagement.ResolveException: Error downloading org.jetbrains.kotlinx:kotlinx-html-jvm:0.7.
[error]   Not found
[error]   not found: /home/piquerez/.ivy2/local/org.jetbrains.kotlinx/kotlinx-html-jvm/0.7.2/ivys/ivy.xml
[error]   not found: https://repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-html-jvm/0.7.2/kotlinx-html-jvm-0.7.2.pom
[error] Error downloading org.jetbrains:markdown:0.1.45
[error]   Not found
[error]   not found: /home/piquerez/.ivy2/local/org.jetbrains/markdown/0.1.45/ivys/ivy.xml
[error]   not found: https://repo1.maven.org/maven2/org/jetbrains/markdown/0.1.45/markdown-0.1.45.pom

So I have no other choice than temporarily add jcenterRepo in the list of resolvers...

@adpi2 @eed3si9n would it be possible to give us a few weeks to migrate away from Dokka? It should make our classpath much shorter, and we will be able to get rid of centre.

Jackson: we are using it for some things but we should be able to remove that if we really need

It looks like you're using it to parse yaml, but you're also using flexmark to do that, are both really needed?

We can take a look at it after migration away from dokka.

@romanowski I think it largely depends on when Scala 3 final is coming out and when sbt 1.5.0 is expected to arrive.
Normally the RC cycle takes a few months (every fresh code has bugs) so I was hoping to ship sbt 1.5.0-RC1 this month.
If we're still on schedule with https://www.scala-lang.org/blog/2020/12/15/scala-3-crossing-the-finish-line.html, then I think we should try to get sbt 1.5.0-RC1 out before Scala 3.0.0-RC1 to test all the JAR naming conventions.
So maybe you do have 2 ~ 3 weeks, including this week, but it might be good to just make assembly JAR and push it to Maven Central for the 3.0 version, and do the refactoring afterwards.
Either case, I'll defer the timing decision to @darjutak

@romanowski
sbt is not really depending on a particular version of scala3doc: the scala3doc artifacts are fetched at runtime depending on the scalaVersion. This should keep being true as long as the Scala 3 compiler and scala3doc are released together and use the same version number.
If all goes well, the next scala3doc version is 3.0.0-RC1. So maybe its preferable to release a first milestone of sbt that is compatible with scala3doc:3.0.0-M3 (so using JCenter by default). Once everybody has jumped to 3.0.0-RC1 we can drop jcenter and after a few weeks/months release sbt 1.5.0.
So it's great if you can migrate away from Dokka and if we can get rid of jcenter. Also I think it will not confilct with the sbt timeline.

The 3 PRs that are related to scala3doc are ready for review:

https://github.com/sbt/librarymanagement/pull/359
https://github.com/sbt/zinc/pull/960
https://github.com/sbt/sbt/pull/6234

JCenter is not added by default. The user must set resolver += Resolver.JCenterRepository to be able to run the doc task on a Scala 3 project. But all other tasks should work fine with or without JCenter. This is meant to be temporary.
Please tell me if you think this is a good strategy or not. It may not be the right timing. If so we can delay the merging of these PRs.

@eed3si9n and others I am trying to implement
("a" % "b" % "1.0").cross(CrossVersion.for3Use2_13)

The cross method takes a subtype of CrossVersion:

Disabled
Binary(prefix: String, suffix: String)
Constant(value: String)
Full(prefix: String, suffix: String)
Patch

Those subtypes used to be generated but they are not anymore, since https://github.com/sbt/librarymanagement/pull/296.
The binaryMapped logic was dropped in sbt 1.0 (see https://github.com/sbt/librarymanagement/pull/117)
So I see 3 possible implementations:

Add a class For3Use2_13() extends CrossVersion with Serializable and similarly a For2_13Use3
Reintroduce a class BinaryMapped(f: String => String) extends CrossVersion but which cannot be Serializable and so escapes CrossVersionFormats (idk what  CrossVersionFormats is used for)
Use Constant like withDottyCompat does, meaning that for3Use2_13 takes a scalaVersion:

("a" % "b" % "1.0").cross(CrossVersion.for3Use2_13(scalaVersion.value))

What's your take on it?

@eed3si9n and others I am trying to implement
("a" % "b" % "1.0").cross(CrossVersion.for3Use2_13)

The cross method takes a subtype of CrossVersion:

Disabled
Binary(prefix: String, suffix: String)
Constant(value: String)
Full(prefix: String, suffix: String)
Patch

Those subtypes used to be generated but they are not anymore, since https://github.com/sbt/librarymanagement/pull/296.
The binaryMapped logic was dropped in sbt 1.0 (see https://github.com/sbt/librarymanagement/pull/117)
So I see 3 possible implementations:

Add a class For3Use2_13() extends CrossVersion with Serializable and similarly a For2_13Use3
Reintroduce a class BinaryMapped(f: String => String) extends CrossVersion but which cannot be Serializable and so escapes CrossVersionFormats (idk what  CrossVersionFormats is used for)
Use Constant like withDottyCompat does, meaning that for3Use2_13 takes a scalaVersion:

("a" % "b" % "1.0").cross(CrossVersion.for3Use2_13(scalaVersion.value))

What's your take on it?

IMO we should go for class For3Use2_13() so ModuleID and UpdateReport etc can be persisted to JSON (plain function cannot be translated into JSON). Scala version info is given separately later for %% so that should not be part of the cross.

IMO we should go for class For3Use2_13() so ModuleID and UpdateReport etc can be persisted to JSON (plain function cannot be translated into JSON). Scala version info is given separately later for %% so that should not be part of the cross.

Also I guess I should add a prefix field for scala.js and Scala native as in Binary (example in ScalaJSPlugin) and a suffix.
So it is:
class For3Use2_13(prefix: String, suffix: String) extends CrossVersion with Serializable

and
abstract class CrossVersionFunctions {
  def for3Use2_13: CrossVersion = new  For3Use2_13("", "")

  def for3Use2_13With(prefix: String, suffix: String): CrossVersion = new For3Use2_13(prefix, suffix)
}

Also I guess I should add a prefix field for scala.js and Scala native as in Binary (example in ScalaJSPlugin) and a suffix.
So it is:
class For3Use2_13(prefix: String, suffix: String) extends CrossVersion with Serializable

and
abstract class CrossVersionFunctions {
  def for3Use2_13: CrossVersion = new  For3Use2_13("", "")

  def for3Use2_13With(prefix: String, suffix: String): CrossVersion = new For3Use2_13(prefix, suffix)
}

I am getting close to the end of this project.
The only thing that could be seen as missing compared to sbt-dotty is the isDotty setting that could easily be replaced by a isScala3.value. But should we? I don't have a strong opinion about it. I give you my thoughts then tell me what you think.
isScala3.value
Pros
I think that most people would want it because it is absolutely useful in cross-built projects, to manage the dependencies, the compiler plugins, the scalacOptions among other things.
For instance:
libraryDependencies ++= {
  if (isScala3.value) Nil
  else Seq(compilerPlugin(("org.typelevel" %% "kind-projector" % kindProjectorVersion).cross(CrossVersion.full)))
},
scalacOptions ++= {
  if (isScala3.value) Seq("-Ykind-projector")
  else Nil
}

isDotty.value is called 9 times in the cats build.sbt file alone: https://github.com/typelevel/cats/blob/master/build.sbt
It is more convenient than writing scalaVersion.value.startsWith("3") or any other alternative.
Cons
But it is not really a setting because it is not something that people might want to override. The following code does not make sense:
scalaVersion := "3.0.0-M3",
isScala3 := false

There are plenty of alternatives:
scalaVersion.value.startsWith("3.")
ScalaArtifacts.isScala3(scalaVersion.value)
VersionNumber(scalaVersion.value).matchesSemVer(SemanticSelector(">= 3.0.0-M1"))

Should we add a isScala3 setting and if not which alternative do we advertise (in the migration guide for instance)?

I am getting close to the end of this project.
The only thing that could be seen as missing compared to sbt-dotty is the isDotty setting that could easily be replaced by a isScala3.value. But should we? I don't have a strong opinion about it. I give you my thoughts then tell me what you think.
isScala3.value
Pros
I think that most people would want it because it is absolutely useful in cross-built projects, to manage the dependencies, the compiler plugins, the scalacOptions among other things.
For instance:
libraryDependencies ++= {
  if (isScala3.value) Nil
  else Seq(compilerPlugin(("org.typelevel" %% "kind-projector" % kindProjectorVersion).cross(CrossVersion.full)))
},
scalacOptions ++= {
  if (isScala3.value) Seq("-Ykind-projector")
  else Nil
}

isDotty.value is called 9 times in the cats build.sbt file alone: https://github.com/typelevel/cats/blob/master/build.sbt
It is more convenient than writing scalaVersion.value.startsWith("3") or any other alternative.
Cons
But it is not really a setting because it is not something that people might want to override. The following code does not make sense:
scalaVersion := "3.0.0-M3",
isScala3 := false

There are plenty of alternatives:
scalaVersion.value.startsWith("3.")
ScalaArtifacts.isScala3(scalaVersion.value)
VersionNumber(scalaVersion.value).matchesSemVer(SemanticSelector(">= 3.0.0-M1"))

Should we add a isScala3 setting and if not which alternative do we advertise (in the migration guide for instance)?

Why can't we easily get the Scala version as a Tuple3[Int, Int, Int]?
Also the SemVer thing could have a much nicer DSL.
On Mon, Jan 11, 2021, 5:41 AM Adrien Piquerez<EMAIL_ADDRESS>wrote:

I am getting close to the end of this project.
The only thing that could be seen as missing compared to sbt-dotty is the
isDotty setting that could easily be replaced by a isScala3.value. But
should we? I don't have a strong opinion about it. I give you my thoughts
then tell me what you think.
isScala3.value Pros
I think that most people would want it because it is absolutely useful in
cross-built projects, to manage the dependencies, the compiler plugins, the
scalacOptions among other things.
For instance:
libraryDependencies ++= {
if (isScala3.value) Nil
else Seq(compilerPlugin(("org.typelevel" %% "kind-projector" % kindProjectorVersion).cross(CrossVersion.full)))
},
scalacOptions ++= {
if (isScala3.value) Seq("-Ykind-projector")
else Nil
}
isDotty.value is called 9 times in the cats build.sbt file alone:
https://github.com/typelevel/cats/blob/master/build.sbt
It is more convenient than writing scalaVersion.value.startsWith("3") or
any other alternative.
Cons
But it is not really a setting because it is not something that people
might want to override. The following code does not make sense:
scalaVersion := "3.0.0-M3",
isScala3 := false
There are plenty of alternatives:
scalaVersion.value.startsWith("3.")ScalaArtifacts.isScala3(scalaVersion.value)VersionNumber(scalaVersion.value).matchesSemVer(SemanticSelector(">= 3.0.0-M1"))
Should we add a isScala3 setting and if not which alternative do we
advertise (in the migration guide for instance)?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sbt/sbt/issues/6080#issuecomment-757866207, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAUEZT4CGDKBFQITDHTLSZLIVXANCNFSM4TR7EK4Q
.

Why can't we easily get the Scala version as a Tuple3[Int, Int, Int]?
Also the SemVer thing could have a much nicer DSL.
On Mon, Jan 11, 2021, 5:41 AM Adrien Piquerez<EMAIL_ADDRESS>wrote:

I am getting close to the end of this project.
The only thing that could be seen as missing compared to sbt-dotty is the
isDotty setting that could easily be replaced by a isScala3.value. But
should we? I don't have a strong opinion about it. I give you my thoughts
then tell me what you think.
isScala3.value Pros
I think that most people would want it because it is absolutely useful in
cross-built projects, to manage the dependencies, the compiler plugins, the
scalacOptions among other things.
For instance:
libraryDependencies ++= {
if (isScala3.value) Nil
else Seq(compilerPlugin(("org.typelevel" %% "kind-projector" % kindProjectorVersion).cross(CrossVersion.full)))
},
scalacOptions ++= {
if (isScala3.value) Seq("-Ykind-projector")
else Nil
}
isDotty.value is called 9 times in the cats build.sbt file alone:
https://github.com/typelevel/cats/blob/master/build.sbt
It is more convenient than writing scalaVersion.value.startsWith("3") or
any other alternative.
Cons
But it is not really a setting because it is not something that people
might want to override. The following code does not make sense:
scalaVersion := "3.0.0-M3",
isScala3 := false
There are plenty of alternatives:
scalaVersion.value.startsWith("3.")ScalaArtifacts.isScala3(scalaVersion.value)VersionNumber(scalaVersion.value).matchesSemVer(SemanticSelector(">= 3.0.0-M1"))
Should we add a isScala3 setting and if not which alternative do we
advertise (in the migration guide for instance)?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sbt/sbt/issues/6080#issuecomment-757866207, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAUEZT4CGDKBFQITDHTLSZLIVXANCNFSM4TR7EK4Q
.

Should we add a isScala3 setting and if not which alternative do we advertise (in the migration guide for instance)?

I don't think we should treat Scala 3 any more special than 2.13 etc especially because there might be various conditions the build users may have to make in the future beyond 3.0.
Here's a real-life cross building example that I have on scopt/scopt:
    scalacOptions ++= {
      CrossVersion.partialVersion(scalaVersion.value) match {
        case Some((3, _)) =>
          Seq("-source:3.0-migration")
        case Some((2, v)) if v <= 12 =>
          Seq("-Xfuture")
        case _ =>
          Nil
      }
    },

Not sure if it's the best, but it works for me.

Should we add a isScala3 setting and if not which alternative do we advertise (in the migration guide for instance)?

I don't think we should treat Scala 3 any more special than 2.13 etc especially because there might be various conditions the build users may have to make in the future beyond 3.0.
Here's a real-life cross building example that I have on scopt/scopt:
    scalacOptions ++= {
      CrossVersion.partialVersion(scalaVersion.value) match {
        case Some((3, _)) =>
          Seq("-source:3.0-migration")
        case Some((2, v)) if v <= 12 =>
          Seq("-Xfuture")
        case _ =>
          Nil
      }
    },

Not sure if it's the best, but it works for me.

Again, we can make that way easier without special-casing Scala 3
On Mon, Jan 11, 2021, 3:12 PM eugene yokota<EMAIL_ADDRESS>wrote:

Should we add a isScala3 setting and if not which alternative do we
advertise (in the migration guide for instance)?
I don't think we should treat Scala 3 any more special than 2.13 etc
especially because there might be various conditions the build users may
have to make in the future beyond 3.0.
Here's a real-life cross building example that I have on scopt/scopt
https://github.com/scopt/scopt/blob/8e42dd1de71087e39b0e98dc736cabe79d8e0231/build.sbt#L30-L39
:
scalacOptions ++= {
  CrossVersion.partialVersion(scalaVersion.value) match {
    case Some((3, _)) =>
      Seq("-source:3.0-migration")
    case Some((2, v)) if v <= 12 =>
      Seq("-Xfuture")
    case _ =>
      Nil
  }
},

Not sure if it's the best, but it works for me.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sbt/sbt/issues/6080#issuecomment-758194996, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAUD7FCDJOFNJK4WF7JTSZNLRZANCNFSM4TR7EK4Q
.

Again, we can make that way easier without special-casing Scala 3
On Mon, Jan 11, 2021, 3:12 PM eugene yokota<EMAIL_ADDRESS>wrote:

Should we add a isScala3 setting and if not which alternative do we
advertise (in the migration guide for instance)?
I don't think we should treat Scala 3 any more special than 2.13 etc
especially because there might be various conditions the build users may
have to make in the future beyond 3.0.
Here's a real-life cross building example that I have on scopt/scopt
https://github.com/scopt/scopt/blob/8e42dd1de71087e39b0e98dc736cabe79d8e0231/build.sbt#L30-L39
:
scalacOptions ++= {
  CrossVersion.partialVersion(scalaVersion.value) match {
    case Some((3, _)) =>
      Seq("-source:3.0-migration")
    case Some((2, v)) if v <= 12 =>
      Seq("-Xfuture")
    case _ =>
      Nil
  }
},

Not sure if it's the best, but it works for me.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sbt/sbt/issues/6080#issuecomment-758194996, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAUD7FCDJOFNJK4WF7JTSZNLRZANCNFSM4TR7EK4Q
.

@nafg I think that's exactly the point of @eed3si9n. Or maybe you have something else in mind?

@nafg I think that's exactly the point of @eed3si9n. Or maybe you have something else in mind?

Oh I didn't read it closely enough. Not too bad. But there could be a built
in setting that doesn't return Option (unlike CrossVersion.partialVersion
which takes an arbitrary string), like scalaVersionParts. Has the Scala
version format ever not been x.y.z?
On Tue, Jan 12, 2021 at 3:46 AM Adrien Piquerez<EMAIL_ADDRESS>wrote:

@nafg https://github.com/nafg I think that's exactly the point of
@eed3si9n https://github.com/eed3si9n. Or maybe you have something else
in mind?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sbt/sbt/issues/6080#issuecomment-758502874, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAUAIGD52NQHGVNUQ4BDSZQD6TANCNFSM4TR7EK4Q
.

Oh I didn't read it closely enough. Not too bad. But there could be a built
in setting that doesn't return Option (unlike CrossVersion.partialVersion
which takes an arbitrary string), like scalaVersionParts. Has the Scala
version format ever not been x.y.z?
On Tue, Jan 12, 2021 at 3:46 AM Adrien Piquerez<EMAIL_ADDRESS>wrote:

@nafg https://github.com/nafg I think that's exactly the point of
@eed3si9n https://github.com/eed3si9n. Or maybe you have something else
in mind?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sbt/sbt/issues/6080#issuecomment-758502874, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAUAIGD52NQHGVNUQ4BDSZQD6TANCNFSM4TR7EK4Q
.

Oh dotty. Why did they have that weird version scheme. And there's of
course snapshots, milestones, RCs, etc. So it should be a special type, not
a Tuple3. That way you could could say scalaVersionInfo.value.major == 3.
On Tue, Jan 12, 2021 at 1:21 PM Naftoli Gugenheim<EMAIL_ADDRESS>wrote:

Oh I didn't read it closely enough. Not too bad. But there could be a
built in setting that doesn't return Option (unlike CrossVersion.partialVersion
which takes an arbitrary string), like scalaVersionParts. Has the Scala
version format ever not been x.y.z?
On Tue, Jan 12, 2021 at 3:46 AM Adrien Piquerez<EMAIL_ADDRESS>wrote:

@nafg https://github.com/nafg I think that's exactly the point of
@eed3si9n https://github.com/eed3si9n. Or maybe you have something
else in mind?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sbt/sbt/issues/6080#issuecomment-758502874, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAUAIGD52NQHGVNUQ4BDSZQD6TANCNFSM4TR7EK4Q
.

Oh dotty. Why did they have that weird version scheme. And there's of
course snapshots, milestones, RCs, etc. So it should be a special type, not
a Tuple3. That way you could could say scalaVersionInfo.value.major == 3.
On Tue, Jan 12, 2021 at 1:21 PM Naftoli Gugenheim<EMAIL_ADDRESS>wrote:

Oh I didn't read it closely enough. Not too bad. But there could be a
built in setting that doesn't return Option (unlike CrossVersion.partialVersion
which takes an arbitrary string), like scalaVersionParts. Has the Scala
version format ever not been x.y.z?
On Tue, Jan 12, 2021 at 3:46 AM Adrien Piquerez<EMAIL_ADDRESS>wrote:

@nafg https://github.com/nafg I think that's exactly the point of
@eed3si9n https://github.com/eed3si9n. Or maybe you have something
else in mind?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sbt/sbt/issues/6080#issuecomment-758502874, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAUAIGD52NQHGVNUQ4BDSZQD6TANCNFSM4TR7EK4Q
.

Scala 3 support in sbt is ready to be tested by the users.
I close this issue. For any problem that is related to Scala 3 in sbt please open a new issue and ping me in it.
@eed3si9n can you plan a release for 1.5.0-M1? A fresh librarymanagement version is also needed to have https://github.com/sbt/librarymanagement/pull/361.

Scala 3 support in sbt is ready to be tested by the users.
I close this issue. For any problem that is related to Scala 3 in sbt please open a new issue and ping me in it.
@eed3si9n can you plan a release for 1.5.0-M1? A fresh librarymanagement version is also needed to have https://github.com/sbt/librarymanagement/pull/361.

Sounds good.

Sounds good.

@eed3si9n @adpi2 I am way too late for the party but scala3doc does not depend on dokka or Kotlin since yesterday. We've just decided that we will drop scala3doc in favour of just scaladoc and I will change that this week (https://github.com/lampepfl/dotty/issues/11275)


Panic when undefined route shares a prefix with a defined route

Environment info:

KrakenD version: 2.5.0 CE
System info: docker / kubernetes
Hardware specs:
Backend technology: Go
Additional environment information:

Describe the bug
My gateway has a number of routes that share a prefix -- eg. /accounts/{id}/widgets, /accounts/{id}/gizmos, etc. These endpoints all route as expected. But if a request is received for a non-existent endpoint that uses the common prefix, this causes krakend to panic.
The panic is handled and logged -- the service does not crash -- but no response is sent to the caller.
Your configuration file:

{
    "$schema": "https://www.krakend.io/schema/v3.json",
    "version": 3,
    "timeout": "30000ms",
    "cache_ttl": "300s",
    "port": 3000,
    "name": "example",
    "disable_keep_alives": true,
    "endpoints": [
      {
        "endpoint": "/accounts/{id}/widgets",
        "method": "GET",
        "output_encoding": "no-op",
        "backend": [{...}]
      },
      {
        "endpoint": "/accounts/{id}/gizmos",
        "method": "GET",
        "output_encoding": "no-op",
        "backend": [{...}]
      },
    ...
  ]
}

The backends really don't matter here, we never get there in this example.
Commands used
krakend run -c /etc/krakend/krakend.json
Test commands:
# test invalid/non-existent route
$ curl -H "Authorization: Bearer <omitted>" http://<IP_ADDRESS>:30000/foo
404 page not found

# test valid route
$ curl -H "Authorization: Bearer <omitted>" http://<IP_ADDRESS>:30000/accounts/ff424c23-e5f3-47c8-83a6-1914e55b4231/widgets
<success response omitted>

# test invalid/non-existent route with /accounts/{id} prefix
$ curl -H "Authorization: Bearer <omitted>" http://<IP_ADDRESS>:30000/accounts/ff424c23-e5f3-47c8-83a6-1914e55b4231/foo
curl: (52) Empty reply from server

Expected behavior
I would expect a query against a undefined endpoint to resolve consistently (502, 404, not particularly choosy as long as it's consistent) and not panic.
In my current version of Krakend, the expected behavior is a 404:
$ curl -H "Authorization: Bearer <omitted>" http://<IP_ADDRESS>:30000/foo
404 page not found

instead of:
$ curl -H "Authorization: Bearer <omitted>" http://<IP_ADDRESS>:30000/accounts/ff424c23-e5f3-47c8-83a6-1914e55b4231/foo
curl: (52) Empty reply from server

... which is what happens due to the panic.
Logs
2023/10/25 19:01:43 http: panic serving <IP_ADDRESS>:37996: invalid node type
goroutine 8679430 [running]:
net/http.(*conn).serve.func1()
    /usr/local/go/src/net/http/server.go:1854 +0xbf
panic({0x2973800, 0x356a850})
    /usr/local/go/src/runtime/panic.go:890 +0x263
github.com/gin-gonic/gin.(*node).findCaseInsensitivePathRec(0xc00053f2e0?, {0xc000c8441d?, 0x4801b40?}, {0xc000648980?, 0x28?, 0x1?}, {0x2f, 0x0, 0x0, 0x0}, ...)
    /go/pkg/mod/github.com/gin-gonic/gin@v1.9.0/tree.go:862 +0xa9d
github.com/gin-gonic/gin.(*node).findCaseInsensitivePathRec(0x8?, {0xc000c84416?, 0xc00053f3c8?}, {0xc000648980?, 0x357d600?, 0xc000ab2000?}, {0x2f, 0x0, 0x0, 0x0}, ...)
    /go/pkg/mod/github.com/gin-gonic/gin@v1.9.0/tree.go:778 +0x45d
github.com/gin-gonic/gin.(*node).findCaseInsensitivePathRec(0x0?, {0xc000c84415?, 0x7feb68408188?}, {0xc000648980?, 0xc00053f518?, 0xc00053f560?}, {0x63, 0x0, 0x0, 0x0}, ...)
    /go/pkg/mod/github.com/gin-gonic/gin@v1.9.0/tree.go:778 +0x45d
github.com/gin-gonic/gin.(*node).findCaseInsensitivePathRec(0x0?, {0xc000c84414?, 0x0?}, {0xc000648980?, 0xc000b49b23?, 0x3583488?}, {0x61, 0x0, 0x0, 0x0}, ...)
    /go/pkg/mod/github.com/gin-gonic/gin@v1.9.0/tree.go:778 +0x45d
github.com/gin-gonic/gin.(*node).findCaseInsensitivePath(0xc000c84414?, {0xc000c84414, 0x43}, 0xd8?)
    /go/pkg/mod/github.com/gin-gonic/gin@v1.9.0/tree.go:669 +0x9c
github.com/gin-gonic/gin.redirectFixedPath(0xc000f46500, 0xc000c84414?, 0x8b?)
    /go/pkg/mod/github.com/gin-gonic/gin@v1.9.0/gin.go:691 +0x5b
github.com/gin-gonic/gin.(*Engine).handleHTTPRequest(0xc000582b60, 0xc000f46500)
    /go/pkg/mod/github.com/gin-gonic/gin@v1.9.0/gin.go:629 +0x3aa
github.com/gin-gonic/gin.(*Engine).ServeHTTP(0xc000582b60, {0x7feb3f599730?, 0xc0011308a0}, 0xc000ced000)

Additional context
I'm actually running a custom plugin so my stack trace might look weird (had to remove the bits specific to my company's application due to policy.) However since #779 looks suspiciously like the same thing I'm seeing, I'm quite certain this hasn't anything to do with any custom code.
Due to the nature of my application, I can't use "disable_redirect_fixed_path": true, which I understand from #779 may be a workaround.

Hello @mila-rodriguez-netapp ,
Have you been able to reproduce this behavior in a clean environment without plugins? I just copy/pasted your example, added a default backend and I was unable to reproduce this behavior. Could you provide more input?
{
    "$schema": "https://www.krakend.io/schema/v3.json",
    "version": 3,
    "timeout": "30000ms",
    "cache_ttl": "300s",
    "port": 8080,
    "name": "polariscloud",
    "disable_keep_alives": true,
    "host": ["http://localhost:8080"],
    "debug_endpoint": true,
    "endpoints": [
      {
        "endpoint": "/accounts/{id}/widgets",
        "method": "GET",
        "output_encoding": "no-op",
        "backend": [{"url_pattern": "/__debug/gizmos"}]
      },
      {
        "endpoint": "/accounts/{id}/gizmos",
        "method": "GET",
        "output_encoding": "no-op",
        "backend": [{"url_pattern": "/__debug/gizmos"}]
      }
  ]
}

Curls:
 ~ ❯ curl http://localhost:8080/accounts/12/gizmos
{"message":"pong"}%                                                                                ~ ❯ curl http://localhost:8080/accounts/12/giszmos
404 page not found%                                                                                ~ ❯ curl http://localhost:8080/accounts/12/widgets
{"message":"pong"}%                                                                                ~ ❯ curl http://localhost:8080/accounts/1dasdasd2/widgets
{"message":"pong"}%                                                                                ~ ❯ curl http://localhost:8080/accountsa/1dasdasd2/widgets
404 page not found%                                                                                ~ ❯ curl http://localhost:8080/accounts/1234/widgets
{"message":"pong"}%                                                                                ~ ❯ curl http://localhost:8080/accounts/1234/widgetsaaa
404 page not found%

Same here, my friends.
Here is the conf file. It's kind of large...
curl -i [your-host]/group/v2/units
krakend_config.json

Hey, you are facing a problem as described in the issues  #779, #325,  #386, #423 and #632 related to routing conflicts leading to errors when using automated processes to generate configuration files with multiple endpoints.
This is indeed a known issue with the router package used internally by KrakenD. We have communicated with the maintainers of the router package about this problem twice (https://github.com/gin-gonic/gin/issues/2959). Initially, there was an attempt to fix it, but unfortunately, that effort did not fully resolve the issue. We are waiting for the package maintainers' response to find a permanent solution.
In the meantime, the workaround you've discovered —disabling the automatic redirect— remains the only method to prevent these panics. This situation occurs when a 404 response is expected for a request to a path that overlaps with several patterns but matches none of them.

I've created a new issue in the gin project (https://github.com/gin-gonic/gin/issues/3972), hoping to get some attention because it looks like the old one is getting none since it's already closed and marked as fixed

Hi @alombarte What's the consequences of disabling the automatic redirect? disable_redirect_fixed_path : true


flynnhub.com subdomains blacklisted as deceptive

If I visit flynnhub.com or any associated subdomains in Chrome or Firefox, they are blacklisted as a deceptive site. This is also causing API calls to silently fail to those domains.

I'm investigating this.

I've responded to the report and requested a review.

The site has been marked as safe, the blocklist should update in the next few hours.

Great thanks - this looks to be working here


feature: displaying a warning before opening a block explorer link

Description
I added a new UIAlertController to display an alert to the user when they tap on a block explorer link. I also made a slight refactor to remove the delegate that is passed into EventDetailViewModel.swift. I replaced it with a more reactive approach to more fully embrace that style of programming within the app.
Motivation and Context
This is to address issue #125.
How Has This Been Tested?
On the iOS simulator, I went to the history page, tapped on a transaction and then tapped on both transaction hashes as well as addresses. I verified that the cancel button dismissed the alert in both cases. I also verified that the continue button took us to the correct block explorer page in both instances.
I also went to the channel page and tapped on the funding transactions. I verified that the cancel button dismissed the alert. I also verified that the continue button took us to the correct block explorer page.
Screenshots (if appropriate):

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report

Merging #326 into master will decrease coverage by 0.19%.
The diff coverage is 19.44%.

@@            Coverage Diff            @@
##           master     #326     +/-   ##
=========================================
- Coverage   10.78%   10.58%   -0.2%
=========================================
  Files         247      247
  Lines        9803     9823     +20
=========================================
- Hits         1057     1040     -17
- Misses       8746     8783     +37

Impacted Files
Coverage Δ

Library/Generated/strings.swift
6.97% <ø> (ø)
:arrow_up:

Library/Coordinators/WalletCoordinator.swift
0% <0%> (ø)
:arrow_up:

Library/Extensions/UIAlertController.swift
0% <0%> (ø)
:arrow_up:

...nes/History/Detail/EventDetailViewController.swift
0% <0%> (ø)
:arrow_up:

Library/Tests/EventDetailViewModelTests.swift
97.36% <100%> (+2.49%)
:arrow_up:

...y/Scenes/History/Detail/EventDetailViewModel.swift
36.29% <62.5%> (-1.93%)
:arrow_down:

...htning/Services/Misc/BlockChainHeightUpdater.swift
60.41% <0%> (-35.42%)
:arrow_down:

...htning/Certificates/PinnedURLSessionDelegate.swift
96.55% <0%> (+3.44%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 17f5be1...c5ac5a4. Read the comment docs.

Greenwallet has an option to turn that alert off. that's pretty nice for users who don't care about that notification.
We can just store that in the UserDefaults. (https://github.com/LN-Zap/zap-iOS/blob/master/Library/Extensions/UserDefaults.swift).


Add date time to the log information

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
Setup:
Docker image running manually with recyclarr sync throught unRaid
Sceario:
Im looking to the docker logs in unRaid interface, and I used to have trouble to figured out  when I had run, if the logs are the recent or not.
Propose
Add timestamp to the docker logs.
The current logs is already amazing, and have been improve a lot, I really appreciate it.
I just wonder if we could add a date/time at end of everything (or end of each section), maybe the runtime or something. This would help me to know exactly date/time it had run.

This is fixed in commit aaf810f


[FEAT] Identify the boot manager

Wanted features:
It would be nice to display the boot manager (whether the OS is using GRUB, systemd-boot, etc).
Motivation:
Fastfetch already support the "Bios" module so adding a module for the boot manager would be a valuable addition.

Done. Please test the latest dev build.
Note we support UEFI mode only, because we grab the information from UEFI variables.

I confirm it works fine. Thanks a lot!

What is the firmware?

The BOOTMGR.
Le ven. 17 mai 2024, 00:50, Carter Li @.***> a écrit :

What is the firmware?
—
Reply to this email directly, view it on GitHub
https://github.com/fastfetch-cli/fastfetch/issues/922#issuecomment-2116325917,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADAXIT5TGYIJGZQ4RVBEVLZCUZ2JAVCNFSM6AAAAABHWVAP4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJWGMZDKOJRG4
.
You are receiving this because you authored the thread.Message ID:
@.***>


Windows 11 Ubuntu 20.0.4 LTS  MSTSC constant launch

Version
Version 10.0.22000.376
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
Ubuntu 20.04 LTS
Other Software
Windows Remote Desktop (v10.0.22000.282)
Repro Steps
Install ubuntu 20.04 LTS on Windows 11 after enabling WSL and then configure for WSL version 2
Open process explorer (from PSTools)
You'll see that mstsc.exe is constantly loading
Expected Behavior
With WSLg enabled, it should just launch mstsc.exe ONCE not constantly
Actual Behavior
MSTSC.exe keeps launching over and over and over again, and constantly stealing focus from other apps on Windows 11.
Diagnostic Logs
Example launch command that it is calling over and over again:
mstsc.exe /v:FD5381AC-7B10-4819-BD14-202E7C76F7B1 /silent /hvsocketserviceid:34D15B6B-FACB-11E6-BD58-64006A7986D3  /wslg /plugin:WSLDVC /wslgsharedmemorypath:WSL\FD5381AC-7B10-4819-BD14-202E7C76F7B1\wslg C:\ProgramData\Microsoft\WSL\wslg.rdp

You can work around this issue, by doing the following:
Open Powershell, and run wsl --shutdown
Open File Explorer on Windows 11:

Go to your local profile
Creating a .wslconfig file (or edit the one that is there)
Adding the following text:

[wsl2]
guiapplications=false

Open ubuntu. Now, WSLG is disabled, and MSTSC stops coming up over and over again.


Documentation/examples

I'm intrigued by this concept, although I'm at a bit of a loss as to how it should be used, not least because Gjallarhorn seems to be mutable at its core and Gjallarhorn.Bindable talks about a "fully immutable data model".
Could you provide or link to any documentation or examples? (I've seen the API reference, and it doesn't really explain how to use it.)

Thanks. While intriguing, the samples were complex enough (contained so many nontrivial, unexplained concepts) that I'll have to wait for proper documentation before I delve further into this.

@cmeeren  It's really much simpler than it would appear at first sight.
Just curious what would you like to see at the documentation?
Btw, I saw on your profile the Yarni - It seems like you already know concept (cause as I know Redux was inspired by Elm). So I really can't understand what exactly is causing you difficulties.

I understand the basic concepts, and I'm sure the rest is simpler than it appears at first sight, but without documentation to set the record straight, I only have "first sight" and my own guesses to go on. Some general things I'm unsure about:

The binding model (usage of Component.create)
The role of Framework.application
Framework.CreateApplicationInfo and CreateApp and why these are used in the Android project instead of e.g. an App class, as is normal with Xamarin.Forms
What is Nav
How to to structure the state in a data-driven app where the state doesn't consist of easily defined components like Tree/Forest (I use redux-like architecture with one state tree and one reducer, partitioned into sub-states/reducers for convenience but still inherently coupled and defined in one place)
How to handle side-effects like persistence, HTTP requests, navigation, user dialogs, etc.
Exactly how opinionated Gjallarhorn.Bindable is, i.e., how much of the samples is mandatory, how much is best practices (and more importantly why), and how much is just an example of one way to do things

Slight tangent: I'm also unsure of if/how Gjallarhorn.Bindable has fixed a really annoying problem I have with my current redux-based Xamarin.Forms app: I have the text values of all Entry views in the store so I can control these values (prefill values, clear password fields after successful password change, etc.) and do other logic based off them (enable/disable submit buttons, show validation messages, etc.), but that means every character typed into a text field (based on Entry.TextChanged) goes through the entire redux loop, ultimately resulting in Entry.Text being set programatically (directly or through updating the BindingContext to a new immutable view model, I'm doing the latter) to the value the user just typed. In addition to some slowness, this causes problems since by updating Entry.Text, we're potentially triggering TextChanged again (if the user typed another character before the update loop completed, which is entirely possible), potentially resulting in an infinite loop where the value is changed back and forth. (I've "solved" this by wrapping the TextChanged handlers that dispatch actions in functions that only proceed if a mutable bool update field in the codebehind is false, and I set this to true before changing the BindingContext to the new VM and restore it to false afterward, but this causes a race condition of sorts wherein characters typed by the user can be swallowed and get lost if they occur during the BindingContext switch, this problem doesn't occur often but still more frequently than I'd like.)

"Some general things I'm unsure about:"
@cmeeren That is nice - I think it's better to split the general question to many small questions (like you have done) and ask in the F# Slack (I know you already joined) or in the SO (there even special tag there) or maybe just create a new issue.
"that means every character typed into a text field (based on Entry.TextChanged) goes through the entire redux loop"
I'm not familiar with redux concept - but maybe you can create separate component?(it's just a supposition, anyway I'd wait for an answer @ReedCopsey )


Dialog to input password does not work as expected

Hi, this line is not sufficient to make the dialog input be hidden
.inputType(InputType.TYPE_CLASS_TEXT | InputType.TYPE_TEXT_VARIATION_PASSWORD)

I have also needed to add this
dialog.getInputEditText().setTransformationMethod(PasswordTransformationMethod.getInstance());

Could you make that the dialog automatically does this if as an input type you specify password?

There's more masks required, this is a framework issue more than it's a library issue

Don't understand what you mean by "There's more masks required", could you explain me?

Oh sorry I wasn't actually at my computer when I initially read this.
I remember using pretty much the same thing (http://stackoverflow.com/a/9893496) before, and it worked fine. You're saying you needed the transformation to make it work?

Exactly, I think I saw the same link. Without the transformation the text is not hidden.

It actually works completely fine for me, without setTransformationMethod, if I move setting the inputType to the bottom after setting everything else up for the EditText. However, I will put setTransformationMethod in there just in case it doesn't work on some devices.

https://github.com/afollestad/material-dialogs/releases/tag/v<IP_ADDRESS>

Thanks! :)


"eas update:delete" doesn't work

Build/Submit details page URL
https://expo.dev/accounts/escola-happen/projects/quark/updates/9b93f0e0-43d2-4bdb-b548-2dc17161f85b
Summary
Hey! I'm trying to do an emergency delete of an update group. But I'm getting an error. As a workaround, I just sent a new update.
Managed or bare?
Bare
Environment
expo-env-info 1.0.5 environment info:
System:
OS: Windows 10 10.0.22621
Binaries:
Node: 18.17.1 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
npm: 9.6.7 - C:\Program Files\nodejs\npm.CMD
IDEs:
Android Studio: AI-222.4459.24.2221.10121639
npmPackages:
expo: ^48.0.9 => 48.0.9
react: 18.2.0 => 18.2.0
react-native: ^0.71.4 => 0.71.4
Expo Workflow: bare
Error output
Unexpected server error (Expo error ID: 5d7fea32-af4c-4316-aa96-a7869fa825bc).
Request ID: 5d7fea32-af4c-4316-aa96-a7869fa825bc
Reproducible demo or steps to reproduce from a blank project
Not sure if it's necessary. It should work just like a comand.

hey @yepMad I took a look at our server logs and the issue is that you are passing the wrong argument to the command. You'll need to pass in the group ID, which is the thing I've highlighted in red here:

Please let me know if you are able to delete your update. I will also look into this workflow to make the user experience better so people dont run into this kind of thing in the future


Ch.3 npm start issues and solutions

Hi, I'm in Ch.3, I got some errors and fixed it by myself.
Let me share my solution for other readers.
Error 1:
When I ran npm start first time, following error was occurred.
TypeScript error in /Users/shnjtk/reactts3/chapter03/my-components/src/App.tsx(1,19):
Could not find a declaration file for module 'react'. '/Users/shnjtk/reactts3/chapter03/my-components/node_modules/react/index.js' implicitly has an 'any' type.
  If the 'react' package actually exposes this module, consider sending a pull request to amend 'https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/react`  TS7016

  > 1 | import React from "react";
      |                   ^
    2 | import logo from "./logo.svg";
    3 | import "./App.css";
    4 |

Solution
I added "noImplicitAny": false to compilerOptions in tsconfig.json.
But I know it's just suppressing the error.
Please tell me If anyone knows better solution.
Error 2:
Then, I tried npm start again and got following error.
/Users/shnjtk/reactts3/chapter03/my-components/src/serviceWorker.ts
TypeScript error in /Users/shnjtk/reactts3/chapter03/my-components/src/serviceWorker.ts(29,7):
Cannot find name 'process'. Do you need to install type definitions for node? Try `npm i @types/node`.  TS2580

    27 |
    28 | export function register(config?: Config) {
  > 29 |   if (process.env.NODE_ENV === 'production' && 'serviceWorker' in navigator) {
       |       ^
    30 |     // The URL constructor is available in all browsers that support SW.
    31 |     const publicUrl = new URL(
    32 |       (process as { env: { [key: string]: string } }).env.PUBLIC_URL,

Solution
I added "types": ["node"] to compilerOptions in tsconfig.json.
Error 3:
After that, npm start shows following error.
undefined
TypeScript error in undefined(undefined,undefined):
Cannot find type definition file for 'node'.  TS2688

Solution
Just do following.
$ npm install @types/node

That's it.
I hope this helps other readers.
And thanks for writing this book @carlrip, I'm having fun reading!

Thanks @shnjtk, just doing a npm install when you get the Could not find a declaration file for module 'react' error usually resolves the problem.

Thanks @carlrip for the advice, I'll try it when I get that error.
I'll close this issue.

deu certo para min , ok

Hi, I'm in Ch.3, I got some errors and fixed it by myself.
Let me share my solution for other readers.
Error 1:
When I ran npm start first time, following error was occurred.
TypeScript error in /Users/shnjtk/reactts3/chapter03/my-components/src/App.tsx(1,19):
Could not find a declaration file for module 'react'. '/Users/shnjtk/reactts3/chapter03/my-components/node_modules/react/index.js' implicitly has an 'any' type.
  If the 'react' package actually exposes this module, consider sending a pull request to amend 'https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/react`  TS7016

  > 1 | import React from "react";
      |                   ^
    2 | import logo from "./logo.svg";
    3 | import "./App.css";
    4 |

Solution
I added "noImplicitAny": false to compilerOptions in tsconfig.json.
But I know it's just suppressing the error.
Please tell me If anyone knows better solution.
Error 2:
Then, I tried npm start again and got following error.
/Users/shnjtk/reactts3/chapter03/my-components/src/serviceWorker.ts
TypeScript error in /Users/shnjtk/reactts3/chapter03/my-components/src/serviceWorker.ts(29,7):
Cannot find name 'process'. Do you need to install type definitions for node? Try `npm i @types/node`.  TS2580

    27 |
    28 | export function register(config?: Config) {
  > 29 |   if (process.env.NODE_ENV === 'production' && 'serviceWorker' in navigator) {
       |       ^
    30 |     // The URL constructor is available in all browsers that support SW.
    31 |     const publicUrl = new URL(
    32 |       (process as { env: { [key: string]: string } }).env.PUBLIC_URL,

Solution
I added "types": ["node"] to compilerOptions in tsconfig.json.
Error 3:
After that, npm start shows following error.
undefined
TypeScript error in undefined(undefined,undefined):
Cannot find type definition file for 'node'.  TS2688

Solution
Just do following.
$ npm install @types/node

That's it.
I hope this helps other readers.
And thanks for writing this book @carlrip, I'm having fun reading!

----------->>>>>>>      npm install --save@types/react -D
this will solve your problem

Hi, I'm in Ch.3, I got some errors and fixed it by myself.
Let me share my solution for other readers.
Error 1:
When I ran npm start first time, following error was occurred.
TypeScript error in /Users/shnjtk/reactts3/chapter03/my-components/src/App.tsx(1,19):
Could not find a declaration file for module 'react'. '/Users/shnjtk/reactts3/chapter03/my-components/node_modules/react/index.js' implicitly has an 'any' type.
  If the 'react' package actually exposes this module, consider sending a pull request to amend 'https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/react`  TS7016

  > 1 | import React from "react";
      |                   ^
    2 | import logo from "./logo.svg";
    3 | import "./App.css";
    4 |

Solution
I added "noImplicitAny": false to compilerOptions in tsconfig.json.
But I know it's just suppressing the error.
Please tell me If anyone knows better solution.
Error 2:
Then, I tried npm start again and got following error.
/Users/shnjtk/reactts3/chapter03/my-components/src/serviceWorker.ts
TypeScript error in /Users/shnjtk/reactts3/chapter03/my-components/src/serviceWorker.ts(29,7):
Cannot find name 'process'. Do you need to install type definitions for node? Try `npm i @types/node`.  TS2580

    27 |
    28 | export function register(config?: Config) {
  > 29 |   if (process.env.NODE_ENV === 'production' && 'serviceWorker' in navigator) {
       |       ^
    30 |     // The URL constructor is available in all browsers that support SW.
    31 |     const publicUrl = new URL(
    32 |       (process as { env: { [key: string]: string } }).env.PUBLIC_URL,

Solution
I added "types": ["node"] to compilerOptions in tsconfig.json.
Error 3:
After that, npm start shows following error.
undefined
TypeScript error in undefined(undefined,undefined):
Cannot find type definition file for 'node'.  TS2688

Solution
Just do following.
$ npm install @types/node

That's it.
I hope this helps other readers.
And thanks for writing this book @carlrip, I'm having fun reading!

'npm install @types/react -D'
this will solve your problem number 1


Update README: virtualenvwrapper and/or venv

In README, under the section titled "development environment", we state that virtualenv is recommended.  But what we really assume there is that virtualenvwrapper is installed (that is where mkvirtualenv and workon commands come from), not just virtualenv.
Installing and using virtualenvwrapper requires additional steps, and some knowledge of the tool.  This is fine.  However, Python 3 also ships a built-in venv module which seems to work just fine with FIM. We can use venv like so:
$ git clone git@github.com:fabric-testbed/InformationModel.git
$ cd InformationModel
$ python3 -m venv venv
$ source ./venv/bin/activate
$ pip install --upgrade pip setuptools
(venv) $

(Older versions of pip and setuptools that gets shipped with Python may not always work; which is why pip install --upgrade pip setuptools is a good idea.)
It would be useful to update the README.  We could:

Recommend one or both of virtualenvwrapper and venv.
Add a link to virtualenvwrapper PyPI project, if that is still recommended.
Add instructions for using venv, if using venv is acceptable.

Fixed by fb125a3


Add publish workflow

Codecov Report
Patch and project coverage have no change.

Comparison is base (44725c6) 100.00% compared to head (177f0ff) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #10   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines          330       330
  Branches        64        64
=========================================
  Hits           330       330

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[Bug] checkbox Field (possibly others) without pivot table doesn't work for create or update

Bug report
What I did
I had a code exactly working on backpack 4.1
Controller
CRUD::addField([   // Checklist
            'label'     => 'Sources',
            'type'      => 'checklist',
            'name'      => 'sources',
            'entity'    => 'sources',
            'attribute' => 'name',
            'model'     => "App\Models\Source",
            'pivot'     => false,
            'options'   => (function ($query) {
                return $query->where('accept_income_message', 1)->get()->pluck('name','id');
            }),
        ]);

Model
protected $casts = [
        'sources' => 'array',
    ];

public function sources()
    {
        return $this->hasMany(Source::class);
    }

What happened
Today I tried to use it
Create
$relationValues contains string -   ["2"]

Edit
$model contains string - 2

Value 2 In both cases, this is the entity ID of the model Source
What I've already tried to fix it
perhaps this is partly due to
https://github.com/Laravel-Backpack/CRUD/commit/e647620bad7b70bfb33e8bbafb8f7ec334c06c2d
Is it a bug in the latest version of Backpack?
last version

@pxpm could you please take a look?

Hello @guleswine
Thanks for the report.
I think that if you don't want to save the relation you should use entity=>false, would that help you here ?
But from my understanding if you are at this point, what you are probably looking at is a belongsToMany relation because it seems your sources table is partially static, and you store the selected sources in a sources column in the current table, am I rigth ?
Let me know.

Oh, I had an extra step, the relationship in the model is not needed. Probably for some reason this did not interfere with version 4.1.


fix: removes baseUrl from tsconfig.json

Description
Reduces the potential of import errors by removing the baseUrl: "." option in tsconfig.json.
import { pairwise } from 'utils/pairwise' or similar imports will now raise errors.
I don't think there should be any side effect in this.
What is the purpose of this pull request?

[x] Other

Thanks!


Optimize the clustering algorithm by replacing the complex vertex_array_t with unordered_map

What do these changes do?
The is_rec is construct/destroy with every vertex, no need to use vertex_array_t.  Optimize the clustering algorithm by replacing the complex vertex_array_t with unordered_map

Related issue number

Fixes #1850

Codecov Report

Merging #1861 (9ba84b0) into main (2695783) will decrease coverage by 8.20%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1861      +/-   ##
==========================================
- Coverage   72.99%   64.78%   -8.21%
==========================================
  Files          89       89
  Lines        9804     9804
==========================================
- Hits         7156     6352     -804
- Misses       2648     3452     +804

Impacted Files
Coverage Δ

...aphscope/tests/kubernetes/test_resource_builder.py
0.00% <0.00%> (-100.00%)
:arrow_down:

...on/graphscope/tests/kubernetes/test_demo_script.py
0.00% <0.00%> (-91.75%)
:arrow_down:

python/graphscope/deploy/kubernetes/utils.py
11.90% <0.00%> (-58.58%)
:arrow_down:

python/graphscope/tests/unittest/test_java_app.py
49.33% <0.00%> (-50.67%)
:arrow_down:

python/graphscope/deploy/kubernetes/cluster.py
23.55% <0.00%> (-50.20%)
:arrow_down:

python/graphscope/analytical/app/java_app.py
24.24% <0.00%> (-44.95%)
:arrow_down:

...thon/graphscope/tests/kubernetes/test_with_mars.py
0.00% <0.00%> (-44.83%)
:arrow_down:

python/graphscope/interactive/query.py
41.12% <0.00%> (-38.71%)
:arrow_down:

...n/graphscope/deploy/kubernetes/resource_builder.py
30.59% <0.00%> (-25.95%)
:arrow_down:

python/graphscope/client/rpc.py
76.85% <0.00%> (-15.75%)
:arrow_down:

... and 10 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2695783...9ba84b0. Read the comment docs.


Get-GitHubRepoLogs fills the sentinal workspace with numerious duplicate log entries

Describe the bug
https://github.com/Azure/Azure-Sentinel/issues/1146 aside, the Get-GitHubRepoLogs logic app worked for most of our repositories, however one run produces a huge number of what appear to be duplicate log entires in the Azure Sentinal workspace that the logic app is logging to. See this screenshot for an example where it appears that the logic app has logged the same collaborator for a repo repeatedly:

To Reproduce
Steps to reproduce the behavior:
1 - Deploy and configure as per these instructions https://github.com/Azure/Azure-Sentinel/tree/master/DataConnectors/GitHub
2 - Wait for Get-GitHubRepoLog to run.
Expected behavior
Log entries would only be entered once, not multiple times in one logic app run.

@dicolanl As per my latest comment in https://github.com/Azure/Azure-Sentinel/issues/1146, the root cause appears to be variables containing repo information (commits, contributors ect) not being cleared between repositories resulting in a steady accumulation of data that is sent to the log workspace with each repo processed.

@kirk-spragg  got it.  Logic app should clear on each loop, but to make sure it does we will add a variable = null at the end of each loop.

@kirk-spragg  we updated via #1157
can we close this issue?

yes


docs: Tabs for JavaScript & TypeScript

Signed-off-by: Jeremy Adams<EMAIL_ADDRESS>

Netlify preview is stale for some reason.

Leaving merge for you @jpadams in case you want to add more changes.

Leaving merge for you @jpadams in case you want to add more changes.

I'll leave it for @vikram-dagger to decide to merge 🙌

@vikram-dagger 💪 go for Squash and merge when ready: