Missing fields in spago.dhall

[maxdeviant]

I noticed that the spago.dhalls in the various Contributors projects are missing the following fields:

• license
• repository

I believe these fields are required by some tooling (I think it might be spago bump-version?).

Should we be adding these fields as part of the library standardization effort? It seems like something we could probably get contrib-updater to add for us.

[thomashoneyman]

Hm — yes, we probably should. It could be added to the contrib-updater. Some of this is going to change pretty soon anyway with the new PureScript registry (in the meantime we still publish with Bower), but the registry is going to require these fields so might as well do it now.

[maxdeviant]

I started to look at this briefly, and one of the potential problems I see is that we don't have a Dhall parser in PureScript, so it might make manipulating spago.dhall rather cumbersome.

[thomashoneyman]

We have a utility to transform the spago.dhall file to JSON so it can be manipulated:

https://github.com/purescript-contrib/governance/blob/main/updater/src/Updater/Utils/Dhall.purs

which relies on dhall-json, which provides the ability to transform Dhall to JSON. And given dhall-lang/dhall-haskell#884, it seems that we can go the other way too, and parse Dhall from JSON. That means we could manipulate the file in JSON and then write the result.

[maxdeviant]

That sounds like it should work just fine.

I did see that we were using dhall-json to go from Dhall → JSON, but I wasn't sure if the other direction would be handled.

[thomashoneyman]

I'm curious if @f-f has any ideas on what the migration to the new registry format might look like, before we do this, because if we're already going to build some kind of automatic migration into Spago itself then this will be a bit of wasted work.

[f-f]

Thanks for the ping. I have a couple of thoughts on this:

• I think adding license and repository is good, the migration will require them anyways for packages that you intend to publish
• using dhall-to-json and then json-to-dhall (which we already use in the registry CI, see here) could work in principle, but it won't work for Spago configs. This is because these tools resolve imports in order to normalize the expression, but in the Spago file we have the import for the package set that we want to preserve. So you'd need to do raw AST manipulation, as we do in Spago

So I'd say this is worth doing only if one has access to a Dhall library. Could be worth trying out dhall-purescript?

[maxdeviant]

I had looked at dhall-purescript briefly, but it looks like it's not readily consumable (e.g., it's not published to Pursuit).

I opened MonoidMusician/dhall-purescript#14 to inquire about the state of the library and see if we could get the core parts published to Pursuit.

[f-f]

You don't strictly need for a project to be published to Pursuit in order to use it. You can add it to the local package set, and use spago docs to have docs locally

[maxdeviant]

build some kind of automatic migration into Spago itself then this will be a bit of wasted work.

I'm wondering if building this into Spago might be the better choice?

1. When the new registry is available we may have other, non-Contributors packages that need to add these missing fields in order to be published
2. Spago is written in Haskell, so we could use the canonical Haskell implementation of Dhall

[maxdeviant]

As a side note, I would like to have a Dhall library for PureScript, as I think it would be quite useful. But I get the impression that dhall-purescript would need some work to become that. Looking at the repo, it looks somewhat abandoned and is also intertwined with a separate project of creating a visual Dhall editor.

Not that I want this to become the policy, but I think in this case I'd like to see a Dhall library reside under Contributors (or possibly even Core).