@Evgeny Shvarov you're correct that no further configuration is needed - although if you want to commit direct from the IDE / Web UI you should set up the username/email for attribution.

At a technical level, see: https://github.com/intersystems/git-source-control/blob/main/cls/SourceC...

git-source-control doesn't reference module.xml directly; there's a method in IPM to get the package to which a given "InternalName" (e.g., Foo.Bar.CLS) belongs, so it calls that.

I agree on most of this. A few comments:

"Triple slash - Great idea. TestCoverage - Great tool. Why are they not in a single "powerful" package?"

These tools solve different, distinct problems (although both are related to unit testing). Tools that solve different, distinct problems should be separate packages. If you want to write a single "powerful" package that depends on both of them and maybe adds some glue between them, feel free!

Dependencies:

Packages should use semantic versioning, and dependencies in IPM can be declared in a way that adheres to the semantic versioning contract. It's the responsibility of the dependency repo owner to follow this, and if you don't trust them you can just lock down to the version you tested with.

Also, I'm hoping to get around to reviewing your TestCoverage PR soon - just trying to deal with some CI infrastructure issues, and my day job keeps interfering. smiley

@Kari Vatjus-Anttila I'm just seeing this now. I'm a bit mystified - currently I'm using the same flags with latest-enough IRIS and the latest package manager, and it's fine.

It's possible that the mocking framework is causing issues. It looks like it has its own unit test manager; how does that play alongside the custom TestCoverage unit test manager? Have you made further changes to TestCoverage.Manager?

@Evgeny Shvarov as we've covered in GitHub issues, the business rule issue is a product-level issue (in the new Angular rule editor only, not the old Zen rule editor). I clarified https://github.com/intersystems/git-source-control/issues/225 re: the importable format.

The non-"wrapped" XML export format is importable by git-source-control and, I believe, IPM itself, although not by $System.OBJ.Load. It's just a matter of preference/readability. In a package manager context being loadable by $System.OBJ.Load isn't as important, and while the enclosing <Export> and <Document> tags aren't as annoying for XML files as for XML-exported classes/routines/etc., they're still annoying and distract from the true content of the document.

@Dmitry Maslennikov it's not actually a REST service, I just want a web application where I have full control over behavior of URLs under the application root in ObjectScript. %CSP.REST is the easiest (maybe only?) way to do that.

I ended up implementing Login as follows (which at least mostly works):

/// Called for a REST page in the event of a login being required
ClassMethod Login(skipheader As %Boolean = 1) As %Status [ ProcedureBlock = 0 ]
{
    // Support including logo image (most of the time...)
    Set brokerApp = "/csp/broker/"
    Set brokerName = $Replace(%request.URL,$Piece(%request.URL,"/portal",1),brokerApp)
    If (brokerName '= brokerApp) {
        Set filename = $System.CSP.GetFileName(brokerName)
        If ##class(%Library.File).Exists(filename) {
            Set %response.ServerSideRedirect = brokerName
            Quit $$$OK
        }
    }

    // Redirect with trailing slash (supports above)
    If ($Extract(%request.CgiEnvs("REQUEST_URI"),*) '= "/") && (%request.URL = %request.Application) {
        Set %response.Redirect = %request.Application
        Do %response.WriteHTTPHeader()
        Quit $$$OK
    }

    // Suppress "Access Denied" error message
    If %request.Method = "GET" {
        Set %request.Data("Error:ErrorCode",1) = $$$ERROR($$$RequireAuthentication)
    }

    Quit ##class(%CSP.Login).Page()
}