FHIR Chat · Package-list.json missing category · shorthand

Stream: shorthand

Topic: Package-list.json missing category


view this post on Zulip Jean Duteau (Sep 15 2020 at 06:26):

I'm just seeing a new HL7 Publication rule that the package-list.json needs a category. This must be a new thing because I've never seen this message before. From what I can see, SUSHI won't produce this new field at all.

view this post on Zulip Grahame Grieve (Sep 15 2020 at 06:32):

yes it's new. What I don't understand is why package-list.json has anything at all to do with FSH

view this post on Zulip Jean Duteau (Sep 15 2020 at 06:32):

it doesn't have anything to do with FSH. but SUSHI has a mode that will generate all of the IG "control files" for us. and many of us use it for that.

view this post on Zulip Grahame Grieve (Sep 15 2020 at 06:33):

well, that particular file should not be generated

view this post on Zulip Jean Duteau (Sep 15 2020 at 06:36):

agree to disagree, I guess. because I drive all of my control files - package-list.json, ImplementationGuide-xxx, ig.ini, menu.xml - from one central config file and I like it that way

view this post on Zulip Grahame Grieve (Sep 15 2020 at 06:37):

perhaps you should have asked why I disagree. The workflow for that particular file is quite different to any other file, and you don't author it

view this post on Zulip Jean Duteau (Sep 15 2020 at 06:42):

I just deleted the file, ran the publisher without sushi and it complains that there isn't a package-list.json.

If package-list.json is no longer needed, then the "file not found" error should probably be changed and the SUSHI team should be told that they can stop generating it.

view this post on Zulip Grahame Grieve (Sep 15 2020 at 06:42):

I didn't say it wasn't needed, just that you don't author it. And I already asked the sushi team to stop generating it, but they ignored me

view this post on Zulip Jean Duteau (Sep 15 2020 at 06:43):

huh? it's needed, but I don't author it? where do I get it from then?

view this post on Zulip Jean Duteau (Sep 15 2020 at 06:43):

I just checked all of my other non-SUSHI guides and I authored package-list.jsons there, so I'm missing what you're saying (probably because it's late for me)

view this post on Zulip Grahame Grieve (Sep 15 2020 at 06:44):

when you are going to ask for a new release, you download the latest copy from the canonical URL, and then enter the details that are appropriate for your new release.

view this post on Zulip Grahame Grieve (Sep 15 2020 at 06:44):

it's not a great way to do it, but I haven't figured out how to do it right - it is just the 6 pieces of information the publishing process needs to execute. It really should be part of some 'publish me' form.

view this post on Zulip Grahame Grieve (Sep 15 2020 at 06:45):

so it's likely to go away. But you certainly cannot change anything else about it other than enter the new release details.

view this post on Zulip Grahame Grieve (Sep 15 2020 at 06:46):

which is why I say 'you don't author it' and sushi shouldn't try generating it

view this post on Zulip Jean Duteau (Sep 15 2020 at 06:48):

@Chris Moesel given the above, rather than adding category to the outputted package-list.json, it appears that you need to just stop generating that file altogether as it's not needed to do an actual publishing run and is only needed if you are publishing guides to HL7.

view this post on Zulip Chris Moesel (Sep 15 2020 at 12:22):

@Grahame Grieve, @Jean Duteau -- thanks for tagging me. @Grahame Grieve -- I apologize, as I think perhaps we've miscommunicated in the past, as we didn't intend to ignore you re: package-list.json.

I'm still not sure I fully followed the conversation above, however. As far as I can tell, HL7 packages still require package-list.json, and HL7 authors are still required to maintain it. For example, Eric Haas just updated the US Core package-list.json only six weeks ago. Are you saying that something changed in the last 6 weeks? And if so, and if the publisher still complains about it, we should just direct authors to ignore that?

view this post on Zulip Jean Duteau (Sep 15 2020 at 14:38):

@Chris Moesel The publisher doesn't really complain about it. There is a note in the qa.html if you don't have that file and it is labeled as HL7 Publishing Rules. My take is that if you weren't publishing on HL7 you wouldn't need this file at all. And if you are publishing, it will be created for you and updated when you are actually publishing. So it's not actually needed for ongoing guide development.

view this post on Zulip Lloyd McKenzie (Sep 15 2020 at 14:52):

The HL7 template does need it as an input because it drives the Jira spec file generation (specifically, the list of versions to include in the dropdown). So the file does need to exist in your base folder.

view this post on Zulip Lloyd McKenzie (Sep 15 2020 at 14:52):

That's different from whether Sushi should be generating it.

view this post on Zulip Jean Duteau (Sep 15 2020 at 15:06):

Right, to summarize:
Building non-HL7 IG - no package-list.json needed
Building HL7 IG - package-list.json not needed during development but needed before being published and for use in HL7 JIRA.

view this post on Zulip Elliot Silver (Sep 15 2020 at 15:09):

Lloyd McKenzie said:

The HL7 template does need it as an input because it drives the Jira spec file generation (specifically, the list of versions to include in the dropdown). So the file does need to exist in your base folder.

This is for the HL7 templates only -- what is the requirement/need for the file for non-HL7 IGs?

view this post on Zulip Elliot Silver (Sep 15 2020 at 15:11):

Grahame Grieve said:

when you are going to ask for a new release, you download the latest copy from the canonical URL, and then enter the details that are appropriate for your new release.

It seems we keep overloading the meaning of canonical URLs. Is this a requirement that the canonical URL must actually resolve?

view this post on Zulip Chris Moesel (Sep 15 2020 at 19:39):

Lloyd McKenzie said:

That's different from whether Sushi should be generating it.

OK, so just to clarify... when we talk about SUSHI "generating" package-list.json -- we're talking about SUSHI taking the history data that the author explicitly writes in the config.yaml and translating it to a package-list.json file. The author is still providing all of the relevant data -- so think of it more as a different package-list authoring format than SUSHI "generating" the file out of the ether.

Anyway -- I still feel like there is conflicting information regarding whether it's needed and when it's needed. I get that it's only needed for HL7 projects. ; that is clear. But whether it's cool to have no package-list.json until the very last moment before publishing it for the first time is still unclear to me. @Lloyd McKenzie -- when you say "the HL7 template does need it", do you mean it _eventually_ needs it (at least by publish time) -- or do you mean it should have it from day 1?

view this post on Zulip Grahame Grieve (Sep 15 2020 at 20:00):

@Elliot Silver non-HL7 projects do not require to have package-list.json but I would highly recommend having it, and following the HL7 publishing pattern; there is a very mature bunch of tools to support that. Part of that is that the canonical URL always does (and SHALL) for HL7 IGs. I also highly recommend this.

view this post on Zulip Grahame Grieve (Sep 15 2020 at 20:02):

@Chris Moesel the thing that's different about the package-list.json is the source of truth. The author can't actually make (or correct) entries in it. The publishing process owns it. If you make the author recreate the data elsewhere so that your process can correctly recreate the file, then you're just forcing them to do make work because they don't have any say in what it says

view this post on Zulip Lloyd McKenzie (Sep 15 2020 at 20:07):

Presumably the long-term solution will be for the publishing tool to just do a GET to pull it back when generating the Jira file?

view this post on Zulip Chris Moesel (Sep 15 2020 at 20:07):

@Grahame Grieve -- so until the publishing process actually creates the file, it just shouldn't exist at all in the project? Is that what you're suggesting? Or should there be some kind of stub at least (until publishing takes it over)?

view this post on Zulip Jean Duteau (Sep 15 2020 at 20:25):

I'm not Grahame, but that was what I understood from my conversation last night/this morning. That it doesn't need to exist until the publishing process happens. I tested in all of my guides sushi or otherwise and there is no consequences of not having a package-list.json for non-hl7 guides and non-published hl7 guides. for published hl7 guides, the note in the qa.html basically says - go get the package-list.json file that is on the published site.

view this post on Zulip Lloyd McKenzie (Sep 15 2020 at 20:28):

The requirement for the HL7 template is that it'll spit out a message in the QA until one exists - and the FMG won't let you go to ballot or publish until that message is gone. So it won't interfere with your ability to build

view this post on Zulip Chris Moesel (Sep 15 2020 at 20:37):

OK, SUSHI #603 indicates that support for package-list.json should be removed from SUSHI. Thanks everyone for walking me through that.

view this post on Zulip Jean Duteau (Oct 14 2020 at 15:44):

Is there anyway that you could incorporate this change into a 0.16.1? I have a couple of IGuides that are close to publishing and I don't want to upgrade to 1.0.0 but I need to have SUSHI stop generating the package-list.json.

view this post on Zulip Chris Moesel (Oct 14 2020 at 17:10):

Can you just remove history from the config.yaml and provide your own package-list.json w/ the category instead?

view this post on Zulip Jean Duteau (Oct 14 2020 at 17:12):

i'm trying that now. :)

view this post on Zulip Jean Duteau (Oct 14 2020 at 17:15):

hmm, that works just fine. never mind my request :)

view this post on Zulip Chris Moesel (Oct 14 2020 at 17:15):

That will set you up better for 1.0.0 anyway since history is deprecated there.


Last updated: Apr 12 2022 at 19:14 UTC