FHIR Chat · Package Id Error · IG creation

Stream: IG creation

Topic: Package Id Error

Mounika (Oct 19 2021 at 16:14):

Hi all,
while publishing the IG, getting the below error. Can anyone suggest me how to fix the issue?
image.png

Chris Moesel (Oct 19 2021 at 16:21):

It looks like maybe you have declared that your IG depends on an a package named JoshSandbox.TestPackage version 1.0.1 - and the IG Publisher cannot find that dependency. Do you expect that package to be available in the FHIR registry?

Mounika (Oct 19 2021 at 16:26):

can you tell me how to fix that

Jean Duteau (Oct 19 2021 at 16:29):

do you really want to depend on a package named JoshSandbox?
If you don't, then remove that dependency from your IG.

Mounika (Oct 19 2021 at 16:36):

Okay

Mounika (Oct 19 2021 at 16:36):

Thankyou

Matt Jenks (Nov 03 2021 at 16:35):

Hi. I am seeing a similar failure and I am not quite sure how I introduced it. My IG builds with out a dependency to us core, except I get a few unresolved errors. When I add my us core dependency, I get the attached failure. ig-error.png

I am adding the dependency with the following XML in my ig.xml.

<dependsOn>
<uri value="http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core"/>
<version value="4.0.0"/>
</dependsOn>

If I remove this dependency, the build failure goes away. Any ideas on what I might be doing wrong? Thanks for any insights!

@Richard Braman (FLY.HEALTH) FYI

Jean Duteau (Nov 03 2021 at 16:51):

you have to look for dependencies in your guide. in the past, when we've seen this error, it's because a sample dependency was specified.

Richard Braman (FLY.HEALTH) (Nov 04 2021 at 15:27):

Jean Duteau said:

you have to look for dependencies in your guide. in the past, when we've seen this error, it's because a sample dependency was specified.

There is only one dependency in this Guide. Its US Core. Notably, the build does not fail on my machine. I think this is something left over in the US Core v4 package. JoshSandbox may mean something to @Isaac Vetter

Grahame Grieve (Nov 04 2021 at 18:50):

there is nothing in US core about JoshSandbox. That's a dependency in your base IG

Richard Braman (FLY.HEALTH) (Nov 04 2021 at 19:00):

Grahame Grieve said:

there is nothing in US core about JoshSandbox. That's a dependency in your base IG

@Matt Jenks do you have some remnant package somewhere?

Like I said, I dont get this error when building from the same repo/branch

Grahame Grieve (Nov 04 2021 at 19:19):

the package is probably in your package cache. If you clean your package cache out, you'll probably get the error

Richard Braman (FLY.HEALTH) (Nov 04 2021 at 19:27):

Grahame Grieve said:

the package is probably in your package cache. If you clean your package cache out, you'll probably get the error

We only have one dependency in the IG: Us Core. How do you clear the FHIR package cache? This is blank:
https://wiki.hl7.org/FHIR_Package_cache

Grahame Grieve (Nov 04 2021 at 19:29):

https://confluence.hl7.org/display/FHIR/FHIR+Package+Cache\

Richard Braman (FLY.HEALTH) (Nov 04 2021 at 19:42):

Grahame Grieve said:

the package is probably in your package cache. If you clean your package cache out, you'll probably get the error

I cleared my cache, and now I get the error as well. We have no dependency in this IG, nor have we ever heard of, JoshSandbox.
the only dependency in the IG is:

  <dependsOn>
    <uri value="http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core"/>
    <version value="4.0.0"/>
  </dependsOn>

Please advise.

Grahame Grieve (Nov 04 2021 at 19:44):

can I reproduce this?

Matt Jenks (Nov 04 2021 at 19:52):

@Grahame Grieve We would definitely appreciate your help. I'm on mac and I have cleared my cache as well and I still see it. I've invited you through Github to our private repo. Thanks

Richard Braman (FLY.HEALTH) (Nov 04 2021 at 19:53):

There is one nugget I see in the build log (not sure what it means)

Dependency 'http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core' has no id, so can't be referred to in markdown in the IG (00:54.0720)

Richard Braman (FLY.HEALTH) (Nov 04 2021 at 19:54):

I also notice that the uscore package is not in my package cache

Grahame Grieve (Nov 04 2021 at 19:55):

well, that built fine for me. Which I expected.

Matt Jenks (Nov 04 2021 at 19:55):

@Richard Braman (FLY.HEALTH) Yeah, I think that package id refers to the npm package id. Which we should add.

Grahame Grieve (Nov 04 2021 at 19:56):

you only need an id if you're doing to do funky stuff in the html templates

Grahame Grieve (Nov 04 2021 at 19:56):

it's not the same as the packageId which you can have instead of or was well as the canonical

Grahame Grieve (Nov 04 2021 at 19:57):

so it does build correctly. What's your package cache local folder name?

Grahame Grieve (Nov 04 2021 at 19:58):

and it doesn't have any dependency on us-core as I got it, so you won't have that in your cache

Matt Jenks (Nov 04 2021 at 20:01):

@Grahame Grieve Try either the development or the fix/fhirfly branches. That's where I see the problem.

Matt Jenks (Nov 04 2021 at 20:03):

I found a package cache in ~/.fhir. I don't see one in /var/lib

Grahame Grieve (Nov 04 2021 at 20:03):

ok do you see anything else in ~/.fhir?

Matt Jenks (Nov 04 2021 at 20:04):

package-client and packages directories package-cache.txt

Grahame Grieve (Nov 04 2021 at 20:06):

well, both those branches build fine for me. So .zip up the package-client folder and send it to me somehow

Grahame Grieve (Nov 04 2021 at 20:07):

oh no wait, I just reproduced it

Grahame Grieve (Nov 04 2021 at 20:29):

well, this is interesting. What's totally mystifying is why you get this and others don't.

Matt Jenks (Nov 04 2021 at 20:29):

I agree it is mystifying. I guess we are just lucky!

Grahame Grieve (Nov 04 2021 at 20:29):

so I'm going to explain because I'm not sure how to solve the underlying technical problem. @Matt Jenks you can work around it easily by adding an explicit packageId in your dependency

Grahame Grieve (Nov 04 2021 at 20:30):

the way you refer to a dependency in an IG is

Grahame Grieve (Nov 04 2021 at 20:30):

image.png

Grahame Grieve (Nov 04 2021 at 20:31):

you can provide either a packageId, or a URI.

Matt Jenks (Nov 04 2021 at 20:31):

So add the packageId for my us core dependency?

Grahame Grieve (Nov 04 2021 at 20:32):

internally, all the tools are packageId based. So if you provide a URL and not a packageId, the first thing the tool has to do is convert the URL to a packageId.

Grahame Grieve (Nov 04 2021 at 20:33):

and this is done by

1. looking through the existing packages to see if there's a match to the canonical URL in the package info
2. if that fails, going and consulting packages.fhir.org
3. if that fails, looking through the ci-build information (should only be for things not yet published)
4. if that fails, then the user gets an error

Grahame Grieve (Nov 04 2021 at 20:33):

the package info looks like this:

Grahame Grieve (Nov 04 2021 at 20:34):

{
  "name": "hl7.fhir.us.core",
  "version": "4.0.0",
  "tools-version": 3,
  "type": "fhir.ig",
  "date": "20210628190945",
  "license": "CC0-1.0",
  "canonical": "http://hl7.org/fhir/us/core",
  "url": "http://hl7.org/fhir/us/core/STU4.0.0",
  "title": "US Core Implementation Guide",
  "description": "The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm.\nThese requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Mon, Jun 28, 2021 19:09+0000+00:00)",
  "fhirVersions": [
    "4.0.1"
  ],
  "dependencies": {
    "hl7.fhir.r4.core": "4.0.1",
    "hl7.fhir.uv.bulkdata": "1.0.1",
    "us.nlm.vsac": "0.3.0"
  },
  "author": "HL7 International - US Realm Steering Committee",
  "maintainers": [
    {
      "name": "HL7 International - US Realm Steering Committee",
      "url": "http://www.hl7.org/Special/committees/usrealm/index.cfm"
    }
  ],
  "directories": {
    "lib": "package",
    "example": "example"
  },
  "jurisdiction": "urn:iso:std:iso:3166#US"
}

Grahame Grieve (Nov 04 2021 at 20:34):

so it matches on the canonical URL here

Grahame Grieve (Nov 04 2021 at 20:34):

if consulting packages.fhir.org, then it does

Grahame Grieve (Nov 04 2021 at 20:35):

http://packages.fhir.org/catalog?canonical=http://hl7.org/fhir/us/core

Grahame Grieve (Nov 04 2021 at 20:35):

and this is where it falls over

Grahame Grieve (Nov 04 2021 at 20:35):

I didn't read the api spec carefully enough. I assumed that ?canonical=url would search for the package.json canonical. But no:

With the canonical parameter, you can search for any package that contains a resource that has the canonical url of the given value. The canonical needs to be an exact match. The search does not support partial matching.

Grahame Grieve (Nov 04 2021 at 20:37):

so... there's no way for me to use packages.fhir.org to determine a packageId for a given canonical URL at this time. @Martijn Harthoorn / @Matthijs van der Wielen that's a pretty fatal error from my perspective

Grahame Grieve (Nov 04 2021 at 20:37):

and because of that, and not properly understanding how much trouble I was in, I defaulted to the first returned package from the search above. Hence, JoshSandbox.

Grahame Grieve (Nov 04 2021 at 20:38):

so I know what the problem is, but I can't fix it.

Matt Jenks (Nov 04 2021 at 20:52):

@Richard Braman (FLY.HEALTH) The development branch is now building for me. Would you give it a try? @Grahame Grieve Thanks for the help!!

Martijn Harthoorn (Nov 05 2021 at 08:13):

@Grahame Grieve , interesting confusion. But I think being able to search for a package canonical is valuable thing to add.

Martijn Harthoorn (Nov 05 2021 at 08:37):

So our team will work on this today to allow searching for package canonical.

Martijn Harthoorn (Nov 05 2021 at 15:11):

Have you tried:
http://packages.simplifier.net/catalog?pkgcanonical=http://hl7.org/fhir
:grinning_face_with_smiling_eyes:

Martijn Harthoorn (Nov 05 2021 at 15:11):

(deleted)

Grahame Grieve (Nov 05 2021 at 18:46):

yes that's what I would expect - but looks great, thanks

Last updated: Apr 12 2022 at 19:14 UTC