Remove BuildTargetKind ?

It's currently defined as:
object BuildTargetKind {
  final val Library = 1
  final val Test = 2
  final val App = 3
  final val IntegrationTest = 4
  final val Bench = 5
}

Most build tools do not require the user to classify their projects in such a way, so the best a build tool could do is try to guess using heuristics, but that can also be done by the IDE itself. Moreover, this information is only needed to display something nice to the user, not to compute anything, so there really isn't any reason to keep it in the protocol in my opinion.

Target kinds are useful for clients that want to highlight the nature of a project; for example, an IDE that knows how to run benchmarks can use the Bench target kind to auto-detect benchmarks and allow users to run them from the IDE.
Most of the build tools (sbt, bazel, pants, maven, gradle) have the ability to define targets that are either binaries, library, tests, benchmarks or integration tests; though they do it in different ways.
In Bazel and pants, users define the purpose of a target by choosing the right directive (scala_binary, scala_library, etc). In sbt, maven and gradle, the definition is implicit via the use of Maven configurations (for example, in sbt you add the IntegrationTest configuration to a project that defines integration tests, and likewise for Bench). If a build tool does not know the nature of a build target, it can safely use App as the default.
All in all, the build tool picks the target kind not by heuristics, but by information given by the user.This information cannot be derived from the IDE and it's therefore required in the project.
See discussion in https://github.com/scalacenter/bsp/issues/12, https://github.com/scalacenter/bsp/commit/80e45b4981fedb86f063b9b07406f3154adc0896 and https://github.com/scalacenter/bsp/pull/5.

an IDE that knows how to run benchmarks can use the Bench target kind to auto-detect benchmarks and allow users to run them from the IDE.

I don't understand this, every benchmark framework will have different ways of running them, knowing that something is a benchmark project doesn't give enough information.

Most of the build tools (sbt, bazel, pants, maven, gradle) have the ability to define targets that are either binaries, library, tests, benchmarks or integration tests

How do you define benchmarks and integration tests in bazel or pants for example?

in sbt you add the IntegrationTest configuration to a project that defines integration tests, and likewise for Bench

I don't see a Bench configuration in sbt.

If a build tool does not know the nature of a build target, it can safely use App as the default.

That doesn't seem right, for me an app is something that can be run, a random build target doesn't always have a way to be run, but it probably has some kind of API so "Library" would be a better default, in any case this would need to be documented.

This information cannot be derived from the IDE and it's therefore required in the project.

I still don't see what useful thing the IDE is supposed to do with this information, BuildTargetCapabilities already has canCompile/canRun/canTest which are easy to give semantics to (though I don't see the point of canCompile, in what case do you have a build project that you cannot build?), Test is redundant with canTest, App is redundant with canRun, and IntegrationTest and Bench are too vague to be useful (and probably not something most build tools know about a project anyway).

@smarter IDEs can use the build target kind to display different icons for different targets. IntelliJ does this for example with blue and green colors for directories

Another example application is a UI to run/build/test/package like https://majestic.debuggable.io/
In sbt it's possible to automatically label the "jmh" configuration as benchmarks. Build tools like cargo provide benchmarking out of the box https://doc.rust-lang.org/1.7.0/book/benchmark-tests.html and I wish more build tools would do the same.
I proposed in https://github.com/scalacenter/bsp/issues/12#issuecomment-394963232 to use labels: List[String] to solve the same problem and that approach has the benefit of 1) allowing a server to leave labels empty and 2) introduce new kinds without changing the protocol. Do you think that solution would be an improvement?

I don't understand this, every benchmark framework will have different ways of running them, knowing that something is a benchmark project doesn't give enough information.

If I'm IntelliJ and want to support Jmh in the JVM world in a build-tool agnostic way, knowing that a target is a benchmark simplifies a lot my life! All I need to do is to find the JMH version used by inspecting the classpath of that target and do some class file analysis on its classpath (after compilation) to find the benchmarks that the user defined. With that information, I can already present the user with a UI to select the benchmark to run and tweak the usual JMH parameters.

For me, the problem with the current design is that build servers are forced to provide a BuildTargetKind when the build server might want to return zero or multiple target kinds. I would be open for a discussion on how to improve that situation.

Seems like the agreement is to keep BuildTargetKind unchanged, which means we can close this ticket. Any objections?

From discussion, we agreed to keep BuildTargetKind, but make it more flexible:

kind is a string, not an int enum
we define a set of standard kinds
servers may specify their own more specific kind strings

@smarter the discussed agreement was to remove kind: Int and a field labels: List[String]
trait BuildTarget {
+ def labels: List[String]
}

The labels are free-form and can be used in any way between the client/server to communicate additional categorization of build targets. The server can leave labels empty if it wants.
I agree that clients should use the BuildTargetCapabilities to know whether a target can be tested or know.

The labels are free-form and can be used in any way between the client/server to communicate additional categorization of build targets.

The Language Server Protocol already has a standardized way to announce extra capabilities, it's called dynamic registration: https://microsoft.github.io/language-server-protocol/specification#client_registerCapability I would be very wary of adding another under-specified mechanism, especially without usecases, it defeats the point of having a standard.

I am personally fine with removing the build target kind and not add labels. @jastice ?

Removing labels + kind would require build servers to properly document build target capabilities, currently bloop does
          val capabilities = bsp.BuildTargetCapabilities(
            canCompile = true,
            canTest = true,
            canRun = true
          )

cc/ @jvican

I think using just the capabilities canTest would be enough for IntelliJ, insofar that build targets are generally declared with either compile or test capability in mind, or separated by the tool for the purpose of the protocol.
Agreed something like client/registerCapability seems like a better fit than labels for adding anything more specific or special-cased.

Sounds good, I will follow up with removing kind with no alternative 👍

if my IDE is smart enough to detect that something is a JMH project, then it can do that regardless of whether the project is identified as "Bench" or not

Sometimes knowing for sure that the build tool has defined that project as a benchmark can be critical for both correctness (no false positives) and performance (when the discovery of certain properties is just too expensive). Build tools like bazel and pants, even sbt, allow you to "tag" certain projects with semantics that are important for IDEs/editors.
I still believe that tags (or build target kinds) have a lot more uses on the client side rather than just canCompile, canTest and canRun that can be understood by the client and supported by the specification without the need of bloating the protocol with dynamic registrations or specific support for them.
I'm not convinced this is the right move and I wouldn't be surprised if in several months from now clients need tags to have precise and reliable information about targets that they can use to enrich the user experience or to support concrete frameworks of targets.

If the need for tags / labels arises in the future we can add this functionality. Once we have a clear use case it will be better to design the correct contract.

I agree with Olaf. I strongly believe that the protocol design should be driven by usage, adding things to a protocol is much easier than removing them, so it makes sense to be conservative and only add things when the pain of not having it is being felt.

We have current use cases, supporting specific benchmark frameworks or web frameworks is one. If IntelliJ knows a project is a benchmark, it can try to discover JMH benchmarks and run them from the IDE. If IntelliJ knows a project is a web server, it can also have specific web frameworks support (like it has now for Spring or Play) to toggle actions in the editor like "Profile web server".
I do not believe we should make this decision based on usage. This is a property fundamental to a project. We should not conflate tags with capabilities. They are different and tags give a lot more flexibility to clients to support the previous use cases reliably.

I am not convinced that BuildTargetKind or labels: List[String] is sufficient data to implement interfaces such as "Run benchmark" or "Profile web server". If the protocol is supposed to enable such use-cases, then I believe we will need sit together and design custom endpoints like buildTarget/benchmark or buildTarget/profile, with accompanying BuildTargetCapabilities.
I agree with @smarter that it it is easier to remove than add functionality, especially as the protocol matures. Given it's still early days I lean towards removing BuildTargetKind and don't add labels/tags until we have a better picture of how those fields will be used (I don't have any use-case for them in metals at the moment, and it seems intellij-scala's usage can be replaced with BuildTargetCapabilities.{canTest,canCompile}).

I'm fine with that, so long as we acknowledge these are important entry points we should support in the protocol sooner or later. Labels could have been a way to unblock clients to implement these behaviors without the expensive process of adding them to the protocol explicitly and then updating clients/servers.

Sounds good. Clients and servers should in theory never be blocked by the protocol because they can still agree on implementing custom endpoints on each side.

The IntelliJ-specific problem I have is that I want need to map targets that share the same base directory to a single IntelliJ module. If there is only one target with canTest==true that is fine. But multiple testing targets (eg test and integrationTest) need to be separate somehow, or at least I need to be able to select only the main targets for import and ignore the others. Neither BuildTargetKind nor tags seem like an optimal fit for this purpose, but either are workable. IS there a better way out?

I think a target should have a base directory as one of its attribute

I think a target should have a base directory as one of its attribute

currently I assume the path part of the buildtargetid uri is the base directory. But having a separate baseDirectory uri does not solve the problem I described. In IntelliJ, sources under the same base directory can only be in one of a fixed set of categories: source, test, resource, test resource or excluded. Library dependencies can only be compile, test, runtime, provided. Basically if a target defines something that doesn't map to these concepts I need to ignore it. If I don't have information on these scopes, differing targets will be lumped together in the some scope. That will probably cause user confusion.

Here's a proposal that might address your needs @jastice

Use BuildTargetCapabilities.canTest: Boolean to determine if a target is for test or not.
We update SourceKind in https://github.com/scalacenter/bsp/issues/21#issuecomment-432948810 to have three categories

object SourceItemKind {
  /** Source code that is manually edited by the user. */
  val Source = 1
  /** Data files that are manually managed by the user. */
  val Resource = 2
  /** Automatically generated source by the build and is not
    * intended to be manually edited by the user. */
  val Excluded = 3
}

currently I assume the path part of the buildtargetid uri is the base directory

I think we should consider adding BuildTarget.baseDirectory: Uri to avoid encoding further information in the target URI. It should be an opaque implementation detail in my opinion that accidentally happens to work so far with the bloop server.

@olafurpg The Bazel plugin for IntelliJ treats the whole Bazel workspace as a single module. From there, you have IntelliJ configurations for running/testing Bazel targets.

Here's a proposal that might address your needs @jastice

I don't see how this would work to distinguish between a test and integrationtest config under the same base. The issue here is that these "configs" in sbt parlance have both different sets of sources and different sets of dependencies.

I think we should consider adding BuildTarget.baseDirectory: Uri to avoid encoding further information in the target URI. It should be an opaque implementation detail in my opinion that accidentally happens to work so far with the bloop server.

Somewhat agree, this was confusing for me at first.

I think we should consider adding BuildTarget.baseDirectory: Uri to avoid encoding further information in the target URI. It should be an opaque implementation detail in my opinion that accidentally happens to work so far with the bloop server.

100% agree

But multiple testing targets (eg test and integrationTest) need to be separate somehow, or at least I need to be able to select only the main targets for import and ignore the others

@jastice This seems like a separate issue that should be discussed elsewhere. In any case, I'm not sure I get what we could possibly do in the protocol: if there are indeed two targets with the same base directory that are both tests, or both non-tests, then IntelliJ is free to lump them together in its UI if it cannot handle them in any other way. Also sbt uses separate source directories for the Test and IntegrationTest configuration so shouldn't that be ok ?

@olafurpg : I will defer to @wisechengyi in that regard.

It should be an opaque implementation detail in my opinion that accidentally happens to work so far with the bloop server.

Why does it happen to work accidentally in bloop?

I think we should consider adding BuildTarget.baseDirectory: Uri to avoid encoding further information in the target URI.

What are the objective benefits of this approach?
I like the current encoding where we have a URI for the base directory in the build target directory ID + a query component specifying the id name. I think it's easy to reason about that the ID of a build is defined in terms of these two parameters which are explained in the specification.

@olafurpg @stuhood assuming this was the question:

any insights on how pants/bazel targets map to IntelliJ modules? I am personally fine with adding baseDirectory: Uri to build targets but I'd like to be sure that this does (edit) not impose unintended complications for build tools that support multiple targets within the same directory.

Status quo: Pants tries to map target to intellij module one to one. However, if a directory contains multiple targets, intellij-pants-plugin is packing all them into one module, thus causing unintended behaviors in IntelliJ sometimes. E.g. a resources target and a library target live in the same dir.
Is BuildTarget.baseDirectory supposed to be source root? If that's the case, I can imagine it being useful since Pants does export this info to IntelliJ in order to configure the module correctly.

If another build server uses a different URI encodings for build targets then that would break the IntelliJ Scala client because it infers information encoded in Bloop URIs.

Oh, then it accidentally works in IntelliJ, not bloop :wink:

If we explicitly document the BuildTarget.baseDirectory requirement in the specification then build servers can use any URI-encoding they like for build targets.

Since we're going to have the project root base directory in the bsp connection details, I would prefer that we change the protocol to guarantee that servers use the per-project base directory in the BuildTargetIdentifier.
I would then discuss whether we should keep having the project name in the URI and specify it in the protocol or adding a concrete field to it.

Status quo: Pants tries to map target to intellij module one to one. However, if a directory contains multiple targets, intellij-pants-plugin is packing all them into one module, thus causing unintended behaviors in IntelliJ sometimes. E.g. a resources target and a library target live in the same dir.

This logic will then needed to be done on the IntelliJ side /cc @jastice The protocol will allow you to express this as independent targets. I know there are some efforts on the IntelliJ side to update their project model to work around all of these issues, Justin can talk more about that.

Since we're going to have the project root base directory in the bsp connection details, I would prefer that we change the protocol to guarantee that servers use the per-project base directory in the BuildTargetIdentifier.

I dont think that can work. BuildTargetIdentifier have to be unique by definition, but two projects can share the same baseDirectory (e.g. when cross-compiling).

I dont think that can work. BuildTargetIdentifier have to be unique by definition, but two projects can share the same baseDirectory (e.g. when cross-compiling).

Yup, that's why I follow up in the same comment saying that we should also having the project name in the URI to disambiguate projects that share the same base directory:

I would then discuss whether we should keep having the project name in the URI and specify it in the protocol or adding a concrete field to it.

That means that now you need to specify a format for URIs that every client and every server needs to know how to parse. Why do that when we can just use fields in JSON messages ? Plus, if the BuildTargetIdentifier areom opaque, servers can use whatever representation suits them better without having to maintain any mapping table. For example in my prototype bsp implementation for mill, the BuildTargetIdentifier was just the string you pass to the mill command-line to run this target, that was really convenient.

I didn't marry myself to a solution: I claimed that we could either add a name: String to the build target or have it in the URI and specify it. I prefer that the build target identifier has the URI in its ID, just as any other thing in the protocol has (text document, source items, resource items, etc).
I can understand how it's simpler for your use case, though.

I opened #50 about adding BuildTarget.baseDirectory
@wisechengyi answered in https://github.com/scalacenter/bsp/issues/50#issuecomment-433354334 😊
@andyscott that is an interesting approach! Judging by https://ij.bazel.build/docs/project-views.html, it seems the IntelliJ Bazel plugin doesn't expose the full bazel workspace but only the relevant targets for a single "IDE import".
For the record, the IntelliJ Bazel plugin has tags: List[String] for build targets but apparently only uses it for no-ide to exclude targets from the IDE import, a different use-case than discussed in this issues.

The question remains what to do with BuildTargetKind. My understanding of the problem is that IntelliJ Scala needs a way to pair main/test targets when there are multiple (>2) targets in the same base directory. Keeping BuildTargetKind.{Library,Application,Test,IntegrationTest,Benchmark} doesn't fully solve this problem, but at least helps a bit with determining which targets to pair together.
There is no open proposal to solve this problem 100% so I think it's best that we keep BuildTargetKind unchanged and delay improvements for the next iteration of the spec.
@smarter A build server that is unsure how to populate BuildTargetKind can use the following logic
val kind =
  if (buildTarget.capabilities.canTest) BuildTargetKind.Test
  else if (buildTarget.capabilities.canRun) BuildTargetKind.Application
  else BuildTargetKind.Library

My understanding of the problem is that IntelliJ Scala needs a way to pair main/test targets when there are multiple (>2) targets in the same base directory

Yes, this is what I wrote in the commit message that introduced build target kind:

Even though IntegrationTest and Bench are not supported by, to the
best of my knowledge, any build tool and IDE, it is still beneficial to
have the kind in the build target.
For example, IntelliJ doesn't support IntegrationTest, but if IntelliJ
users want to see the tests that they can run in their projects,
IntelliJ has to show the test main class from both the Test target
kind and IntegrationTest target kind.
Another use case where this is useful is in showing all the imported
targets, no matter if there's support for them or not, in a list of the
UI so that the user can manually trigger a bsp action on them.

There is no open proposal to solve this problem 100% so I think it's best that we keep BuildTargetKind unchanged and delay improvements for the next iteration of the spec.

Wouldn't the solution we all agreed on and that you proposed about tags: List[String] solve this problem? Free-form strings give freedom to both the client and the server.

Wouldn't the solution we all agreed on and that you proposed about tags: List[String] solve this problem? Free-form strings give freedom to both the client and the server.

For my purposes either "kind" or "tags" will work, with tags being a bit more flexible. The "no-ide" tag for instance is a useful feature already supported for other build tools one way or another.


How can I run the application in my local.

Can you provide the procedure to start the application in local for development, i tried starting the application in my local but i was getting many errors as below
"Manifest file is missing or unreadable
Could not load manifest."
And if I try to select the src folder then also many errors were coming
It will be really helpful if you can provide the procedure to start the application in local along with the procedure to load it in the chrome extensions
Thank you.

I copied the mainifest.json and the image files from src\assets\images to dist and then I could load the locally build extension successfully into Chrome

Actully I saw that there's a script for this defined in package.json
So if you execute npm run rebuild then you should have all the correct files in the dist-folder


computed state confuse

I can't understand why can get array relation in Vuex state, but array relation is empty in component getters.
vuex state
state.quests.data[1726].answers=[2569,6656]

component getters
quests[0].answers  is empty

image 1

image 2

Hi! Sorry, I'm not sure what your question is... Is everything working fine but you just want to know why the relationship can be resolved by having an empty array?
If that is the question, then the answer is because Vuex ORM is not using that array (answers) value when resolving the relations via getters. It looks up for the foreign key defined at model schema definition.
Would this answer make sense to you? 😃

It's probably because you use a query and don't request resolving the relationships with the .with(...) method. You'd have to do something like this:
Quest.query().where('id', Number(1234)).with('answers').first()

Ah wait also I think you need to change model definition as following I think.
class Quest extends Model {
  static entity = 'quests'

  static fields () {
    return {
      id: this.attr(null),
      answers: this.hasManyBy(Option, 'answers')
    }
  }
}

class Option extends Model {
  static entity = 'options'

  static fields () {
    return {
      id: this.attr(null),
      qid: this.attr(null),
      quest: this.belongsTo(Quest, 'qid')
    }
  }
}

@kiaking it is not work, the options qid is null. Thank you for your answer.

@ltinyho Hmm... Is't possible for you to create some reproducible example or fiddle for this issue? Not sure what is happening here :/

@ltinyho Hi! I'll be closing this issue due to inactivity. Please feel free to reopen this issue if you can provide some more information! Hope it solved for you.


[MIST-1018] Remove codes related to Tang configuration for MIST query

This PR addressed #1018 by

removing codes related to Tang

Closes #1018

LGTM. I will merge this code.


Authentication with bearer token

My Rest service uses a bearer token for authentication. And in the Swagger UI I see the authentication button. Now I have included logging manager also in Swagger UI, but it is not showing any authentication button. Then when I make a rest call, I get the message "Authorization header was null".
How can I configure the Logging Manager via the application.properties so that it also takes the Bearer Token?

Does
https://github.com/quarkiverse/quarkus-logging-manager#security and https://quarkus.io/guides/security-overview-concept#path-specific-authentication-mechanisms
help ?

I wonder if this is not a OpenApi issue, can you share a reproducer?

Hi Philip,
here a simple version of my rest service.
And now I a have a problem. When I add the part in the applications.properties the server is not starting.
When I delete the part than the server is starting and the logging-mananger rest call's doesn't need authentication.
I don't know why my big rest service is running with the part in the application.properties.
Smtp-Value-Rest.tar.gz

I have a solution for my starting problem. I added
<dependency>     <groupId>io.quarkus</groupId>     <artifactId>quarkus-security</artifactId> </dependency>
Then i get a 403 Forrbidden exception for the logging-manager call's.

Just to double check. Do you still have an issue or are you solved ?

I still have this issue. No auth button for type the bearer token.


User account<EMAIL_ADDRESS>not found in MSAL cache...

Azure Data Studio Version: 1.49.1
OS Version: Darwin arm64 23.5.0

User account<EMAIL_ADDRESS>not found in MSAL cache, please add linked account or refresh account credentials.
This problem has been persistent for a few years, but has gotten worse. None of the solutions on related tickets have helped.
https://github.com/microsoft/azuredatastudio/issues/24104#
https://github.com/microsoft/azuredatastudio/issues/24894
Not a duplicate, because the other threads ask for a new issue to be opened if this recurs.
Steps to Reproduce:

Connect to an Azure database.
Continue working.
Connect again within a few minutes to another Azure database. See error.

Or

Reveal details (click wedge) of Azure SQL Database in the explorer.
See error.

Yes, I have been assiduously clearing the MSAL cache for years, and the problem continues. Would really like to be able to use this tool!
<!-- 🔧 Launch with `azuredatastudio --disable-extensions` to check. —>
Does this issue occur when all extensions are disabled?: Yes

<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. —>

Microsoft.Data.SqlClient.SqlException (0x80131904): User account<EMAIL_ADDRESS>not found in MSAL cache, please add linked account or refresh account credentials.
---> System.Exception: User account 't<EMAIL_ADDRESS>not found in MSAL cache, please add linked account or refresh account credentials.
at Microsoft.SqlTools.Authentication.Authenticator.GetTokenAsync(AuthenticationParams params, CancellationToken cancellationToken) in //src/Microsoft.SqlTools.Authentication/Authenticator.cs:line 129
at Microsoft.SqlTools.Authentication.Sql.AuthenticationProvider.AcquireTokenAsync(SqlAuthenticationParameters parameters) in //src/Microsoft.SqlTools.Authentication/Sql/AuthenticationProvider.cs:line 90
at Microsoft.Data.SqlClient.SqlInternalConnectionTds.<>c__DisplayClass147_1.<b__1>d.MoveNext()
--- End of stack trace from previous location ---
at Microsoft.Data.SqlClient.SqlInternalConnectionTds.GetFedAuthToken(SqlFedAuthInfo fedAuthInfo)
at Microsoft.Data.SqlClient.SqlInternalConnectionTds.GetFedAuthToken(SqlFedAuthInfo fedAuthInfo)
at Microsoft.Data.SqlClient.SqlInternalConnectionTds.OnFedAuthInfo(SqlFedAuthInfo fedAuthInfo)
at Microsoft.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at Microsoft.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at Microsoft.Data.SqlClient.SqlInternalConnectionTds.CompleteLogin(Boolean enlistOK)
at Microsoft.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, Boolean withFailover)
at Microsoft.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout)
at Microsoft.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance)
at Microsoft.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, Boolean applyTransientFaultHandling, String accessToken, DbConnectionPool pool)
at Microsoft.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
at Microsoft.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions)
at Microsoft.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)
at Microsoft.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)
at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
at Microsoft.Data.ProviderBase.DbConnectionPool.WaitForPendingOpen()
--- End of stack trace from previous location ---
at Microsoft.Data.SqlClient.SqlRetryLogicProvider.ExecuteAsync(Object sender, Func1 function, CancellationToken cancellationToken)    at Microsoft.Data.SqlClient.SqlRetryLogicProvider.ExecuteAsync(Object sender, Func1 function, CancellationToken cancellationToken)
at Microsoft.SqlTools.ServiceLayer.Connection.ReliableConnection.ReliableSqlConnection.<>c__DisplayClass31_0.<b__0>d.MoveNext() in //src/Microsoft.SqlTools.ManagedBatchParser/ReliableConnection/ReliableSqlConnection.cs:line 342
--- End of stack trace from previous location ---
at Microsoft.SqlTools.ServiceLayer.Connection.ConnectionService.TryOpenConnection(ConnectionInfo connectionInfo, ConnectParams connectionParams) in //src/Microsoft.SqlTools.ServiceLayer/Connection/ConnectionService.cs:line 712
ClientConnectionId:4418d2b3-55df-4d7b-a1d4-37c921ce308e


Automatic recursive summary of all attributes in a package

Sphinx autosummary has a resursive option, which essentially find all functions, methods, classes, etc in a package and documents them automatically without the need to type in the name of each one of them. This is very helpful for large APIs. When I looked through the videos and docs for quartodoc, I didn't see a similar option. Is there a way to achieve this with quartodoc currently or does one need to type out each name individually?
Related links:

https://www.sphinx-doc.org/en/master/usage/extensions/autosummary.html
https://stackoverflow.com/questions/2701998/automatically-document-all-modules-recursively-with-sphinx-autodoc

Hey, sorry for the wait, and thanks for digging into this. Do you have any examples of tools using recursive?
I'm a bit stumped--since I know of the option, but have never seen it in practice. For example, pandas, polars, numpy, IPython, scikit. (I'm sure there's a package out there that uses it, and would be curious to see!).

Is there a way to achieve this with quartodoc currently or does one need to type out each name individually?

I wonder if one of these two things could get close to what you're looking for (see documenting members):

If you add a module name to your config, it should document all the classes and functions in it (that are "public", by be being included in the __all__ variable).
If you add a class name to your config, it should document all the functions and attributes on it.

If you can point to the package you're looking to document, I'm happy to take a look!

Thank for the reply! I didn't realize that it was already possible to recursively add class by including the module name in the config. That should probably be enough for my use case then.
Regarding tools using recursive, I think you're right that many of the most popular don't. I wonder if it is because it is newer or because of the limitations listed in https://github.com/sphinx-doc/sphinx/issues/7912 . I noticed that there is a sphinx theme that tries to solve this by including their own api generation for all python functions, leaving it here in case it is useful https://sphinx-immaterial.readthedocs.io/en/latest/apidoc/python/apigen.html. Since it seems like quartodoc already might have enough functionality via the methods you mentioned, I will close this an re-open if I run into issues with the above approaches, thanks again!

Thanks for digging in more -- it seems like there will be some helpful threads to pull with apigen!


crank.js

I'm creating a realworld app for a new ui library crank.js.
The repo is here

Hello we are currently moving all work in progress to Github Discussions.
I'll close this issue by now, you can find instruction to open a discussion there : https://github.com/gothinkster/realworld/discussions/633
Thanks for your contribution !


BAH-3126 | Fix. Recreate Forms To Reflect CIEL Changes

Jira -> https://bahmni.atlassian.net/browse/BAH-3126
Currently, Bahmni utilizes forms that were created when the OCL CIEL (11.06.2022) mappings did not include the Critical High, Normal High, Normal Low, and Critical Low values for each concept. However, OCL has included these missing values in the version (12.22.2022) and we already have CIEL version on our Database.
To maintain data consistency and enhance form functionality, it is essential to update the existing Bahmni forms with the latest OCL CIEL mappings.
The following forms have been updated

Vitals

Second Vitals

Registration Details

Tested in local, no issues observed.