FHIR Chat · dependsOn IG errors

What is the thinking around IG Publisher errors that are caused by a dependency on another IG. We are getting two such errors in eCR - one is an invariant error in US Core that I've raised a JIRA for (https://jira.hl7.org/browse/FHIR-25459?filter=12653) and the other is an ODH error that I'm working on getting to the bottom of.

I could remove the examples from the eCR IG which would remove the errors, but then implementers won't have an example.

Are these errors we can supress?

Lloyd McKenzie (Jan 14 2020 at 23:36):

Right now, errors aren't suppressible. (In part because implementers who use the validator are going to hit them too - so when preparing to do a release we need to consciously decide if that's ok or not.)

Lloyd McKenzie (Jan 14 2020 at 23:36):

Only exception is broken link issues

Sarah Gaunt (Jan 15 2020 at 00:12):

Yes, that's my worry - that implementers are going to hit them. I guess the only option, then, is to remove the examples from the IG. (Which won't help implementers at all... )

Lloyd McKenzie (Jan 15 2020 at 00:16):

The examples aren't the issue. The issue is that real valid data will be flagged as in error.

Lloyd McKenzie (Jan 15 2020 at 00:18):

If you must publish before the IG you depend on can be fixed, you might want to flag the known issue in your IG. (And Perhaps point to the validation results of your example as an example.

Sarah Gaunt (Jan 15 2020 at 00:26):

Well, the examples are the issue for our IG - we really don't want errors in our QA. But yes, agree about real data.

That's the issue, I'm not sure we want those examples with errors showing up in our IG. Especially as hopefully it will be a short term issue in that they will be fixed soon and then we have an IG out there published with errors and explanations about errors that are no longer relevant. Very messy, IMO.

Sarah Gaunt (Jan 15 2020 at 00:31):

I do think that it should be a requirement for all FHIR IGs (like CDA IGs require) that they have at least one example for each profile. Creating examples is a very important QA step. The ODH one doesn't have any examples (and I found another issue when creating examples for eCR of an invalid profile earlier - it was just lucky it was before publication so it could be fixed). This latest one didn't actually show up until I was able to declare the dependency after it was published.

Lloyd McKenzie (Jan 15 2020 at 00:33):

Agree re: at least one example per profile. I'll add it for FMG discussion. I wouldn't worry about QA errors in your IG when you go to publication so long as they've been waved by the FMG/Grahame. Numerous others have gone to publication that way.

Sarah Gaunt (Jan 15 2020 at 00:34):

Ok. Not sure whether the client is going to be ok with that though. We'll see...

Thanks for adding it to FMG discussion!

Lloyd McKenzie (Jan 15 2020 at 00:36):

They have the option of waiting for the dependent IG to be fixed... :)

Sarah Gaunt (Jan 15 2020 at 00:39):

Yeah, no. Been waiting too long for it to be published already!

Grahame Grieve (Jan 15 2020 at 00:47):

Grahame hasn't waived these yet

Sarah Gaunt (Jan 15 2020 at 00:47):

Exactly!

Sarah Gaunt (Jan 15 2020 at 00:49):

BTW, this is the eCR IG that has already been approved for publication by FMG, with the caveat that we needed to add ODH as a dependency before publication. Which has caused errors. But only if we include the ODH examples...

Jens Villadsen (Apr 21 2020 at 09:09):

I have an error in my IG when adding dependsOn https://build.fhir.org/ig/hl7dk/dk-medcom/branches/master/failure/build.log

I had the idea that I should state the packageId from the IG that I depend on - being the package ID from http://build.fhir.org/ig/hl7dk/dk-core/ which is dk.fhir.ig.dk-core. Clearly this is not what is expected. What else should I have written @Grahame Grieve ?

Jens Villadsen (Apr 21 2020 at 10:16):

token error fixed - now the NpmPackageManager is unable to find spec.internals:

Installing dk.fhir.ig.dk-core#0.9.0 to the package cache
  Fetching:
  Installing:  done.
Publishing Content Failed: Unable to find the file other/spec.internals in the package dk.fhir.ig.dk-core (00:15.0392)
                                                                                 (00:15.0392)
Use -? to get command line help                                                  (00:15.0392)
                                                                                 (00:15.0392)
Stack Dump (for debugging):                                                      (00:15.0392)
java.io.IOException: Unable to find the file other/spec.internals in the package dk.fhir.ig.dk-core
    at org.hl7.fhir.utilities.cache.NpmPackage.load(NpmPackage.java:563)

Jens Villadsen (Apr 21 2020 at 10:19):

So where was it downloaded from? fetching the http://build.fhir.org/ig/hl7dk/dk-core/package.tgz shows that there indeed is a spec.internals

Grahame Grieve (Apr 21 2020 at 10:28):

ahh. that is a simplifier package. It's getting downloaded from packages.fhir.org, which at this time only contains the simplifier packages. And they don't have any way for me to depend on them when publishing a fhir IG

Jens Villadsen (Apr 21 2020 at 10:28):

I'll happily do registration on https://github.com/FHIR/ig-registry/blob/master/fhir-ig-list.json

Jens Villadsen (Apr 21 2020 at 10:29):

the only hosting I currently have is the https://build.fhir.org/

Grahame Grieve (Apr 21 2020 at 10:29):

but if it's published through simplifier, then it'll automatically be picked up. The problem is that I can't use packages published through simplifier

Jens Villadsen (Apr 21 2020 at 10:29):

as in https://build.fhir.org/ig/hl7dk/dk-core/

Jens Villadsen (Apr 21 2020 at 10:30):

right ...

Grahame Grieve (Apr 21 2020 at 10:30):

well, you don't need to register a current package - that automatically works. But that's not a stable target to reference

Jens Villadsen (Apr 21 2020 at 10:30):

but is it enough to add the entry in the https://github.com/FHIR/ig-registry/blob/master/fhir-ig-list.json ?

Jens Villadsen (Apr 21 2020 at 10:30):

I don't need stable right now

Jens Villadsen (Apr 21 2020 at 10:30):

fluctuating is fine

Jens Villadsen (Apr 21 2020 at 10:31):

aka [latest] / current

Grahame Grieve (Apr 21 2020 at 10:31):

you don't need to register it at all to refer to the current build - that automatically works for the java package manager

Jens Villadsen (Apr 21 2020 at 10:31):

so what should I do?

Grahame Grieve (Apr 21 2020 at 10:31):

I'm not sure what you're trying to achieve right now, so I don't know what you should do

Jens Villadsen (Apr 21 2020 at 10:31):

I have a moving target dk-core and I need dk-medcom to depend on that moving target

Jens Villadsen (Apr 21 2020 at 10:32):

is that possible?

Grahame Grieve (Apr 21 2020 at 10:34):

you have to make your dependency dk.fhir.ig.dk-core#current - that says to depend on the ci-build version not the version you published through simplifier

Jens Villadsen (Apr 21 2020 at 10:36):

<dependsOn id="DKCore">
        <uri value="http://hl7.dk/fhir/core/ImplementationGuide/dk.fhir.ig.dk-core" />
        <packageId value="dk.fhir.ig.dk-core" />
        <version value="0.9.0" />
    </dependsOn>

should be

<dependsOn id="DKCore">
        <uri value="http://hl7.dk/fhir/core/ImplementationGuide/dk.fhir.ig.dk-core" />
        <packageId value="dk.fhir.ig.dk-core" />
        <version value="#current" />
    </dependsOn>

Jens Villadsen (Apr 21 2020 at 10:36):

or without the '#'

Grahame Grieve (Apr 21 2020 at 10:36):

without the #

Grahame Grieve (Apr 21 2020 at 10:43):

if you're going to publish through simplifier you might want to take up the question with them of how they're going to deal with the publishing problem.