Add `spago publish`

[f-f]

This is Step 2 in the publishing flow described in https://github.com/spacchetti/spago/issues/142#issuecomment-473684622

We'd add a spago publish to push a new version to both the Bower registry and package-sets. It would:

• make sure that some fields necessary for publishing are specified in the spago.dhall: repo, license, version (not sure about this last one, should we get it from the git tag?) This means that the people not publishing a library will not have to have these fields defined (i.e. we should have a PublishingConfig type on the Haskell side, and try to conform the config to that instead of the normal Config type)
• generate an ephemeral bower.json in a temp directory (maybe we need to copy the whole sources for it to work, as I don't seem to find an option to tell bower to use a config file from somewhere else than the current folder). The idea here is that generating a Bowerfile is reproducible from a spago.dhall, so you shouldn't need to include a bower.json in your repo. The versions of packages specified as dependencies can come from the package set or can probably be * (I think there are drawbacks to either choice: one is too restrictive, the other too permissive)
• call git and bower commands in the background to publish a git tag and publish on the bower registry (note: this would require bower to be in the path, if not we should tell people to install bower)
• print out a link to open an issue in package-sets about adding the package there (basically #72)

[hdgarrood]

I like this. I'd suggest not having the version in a manifest file, as if you write a bower.json file with a version key, I suspect it will be ignored by all other tooling which makes use of bower.json files. It will definitely be ignored by purs publish and by bower, both of which go by git tags instead.

For version bounds, I'd suggest generating ^x.y.z when the relevant package set contains version x.y.z. This is more or less what stack's --pvp-bounds option does: https://www.fpcomplete.com/blog/2015/09/stack-pvp. It's also what almost all bower users do in practice. It should probably be possible for authors to exercise more control over version bounds if they want to as well; for example, if a package is known to work with both v2.x and v3.x of one of its dependencies, I think it's useful for the author to be able to express that.

Finally, I'd suggest having this command also run purs publish and upload the produced documentation to Pursuit. You could look at the implementation of pulp publish for inspiration: https://github.com/purescript-contrib/pulp/blob/master/src/Pulp/Publish.purs

[f-f]

@hdgarrood turns out the bower.json cannot be ephemeral, but has to be versioned, see https://github.com/spacchetti/spago/issues/203#issuecomment-493353090

To address your points:

I'd suggest not having the version in a manifest file, as if you write a bower.json file with a version key, I suspect it will be ignored by all other tooling which makes use of bower.json files. It will definitely be ignored by purs publish and by bower, both of which go by git tags instead.

Cool, git tags it is then 👍

For version bounds, I'd suggest generating ^x.y.z when the relevant package set contains version x.y.z

Agreed, this was what I meant above with "the versions of packages specified as dependencies can come from the package set"

It should probably be possible for authors to exercise more control over version bounds if they want to as well; for example, if a package is known to work with both v2.x and v3.x of one of its dependencies, I think it's useful for the author to be able to express that.

Bounds across major versions are good, but I think we could skip this for the first implementation of this, as it brings some questions: e.g. how should this play with #165? (where we're removing the dependencies key in the config - I guess we could have it optional and partial, i.e. you wouldn't have to list all the deps? But then would it be confusing, maybe?)

Finally, I'd suggest having this command also run purs publish and upload the produced documentation to Pursuit. You could look at the implementation of pulp publish for inspiration: https://github.com/purescript-contrib/pulp/blob/master/src/Pulp/Publish.purs

Agreed 👍

[hdgarrood]

Come to think of it, perhaps package authors who do want to exercise that level of control over their bower.json files should just continue to use the workflow described in https://github.com/spacchetti/spago#publish-my-library.

[ajnsit]

How can we generate a bower file from the current spago deps?

[f-f]

@ajnsit let's say you have the following spago.dhall:

{ name = "some-project"
, dependencies = [ "effect", "console", "psci-support" ]
, packages = ./packages.dhall
, license = "MIT"
, repo = "https://github.com/ajnsit/purescript-some-project.git"
}

Then the only non-straightforward thing to figure out for the conversion is the versions for the dependencies. We can look them up in the package set (as every Package has a version field), so with the versions currently in the package set we'd get the following bower.json:

{
  "name": "purescript-some-project",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "https://github.com/ajnsit/purescript-some-project.git"
  },
  "ignore": [
    "**/.*",
    "node_modules",
    "bower_components",
    "output"
  ],
  "dependencies": {
    "purescript-console": "^4.2.0",
    "purescript-effect": "^2.0.1",
    "purescript-psci-support": "^4.0.0"
  }
}

Aside: you can see the versions of the direct dependencies of your spago project by doing spago list-packages -f direct

@ajnsit does it make sense? If you'd like to dive into this I can give you more pointers to actual code

[ajnsit]

I was actually looking for something automated. However spago list-packages -f direct takes me a long way. I can probably wrap some tooling around that, so that was very helpful. Thanks!

[f-f]

@ajnsit you're welcome! We don't have any automation about this in Spago yet, and in fact automating this process is a part of what this issue is about 🙂

[bbarker]

If a branch is created for this, can it be referenced here? Thank!

[f-f]

@bbarker fix up in #396

[bbarker]

@f-f great, I saw that recently!

[f-f]

Superseded by #766