Optional VCS Support in `cabal sdist` (and all-in-one updist workflow)

[gbaz]

It would be nice to have a one-step process for releasing packages. Suppose we had cabal sdist --vcs, initially configured to work with git alone, but easily extensible.

Running this would rely on the upstream repo in the cabal file being set correctly. Having done so it would:

• Confirm that the source-repo state matched the head of the branch
• Tag the branch, update the cabal file to point to the correct tag (using the sadly underused tag field component of the repo field), and push.
• build the tarball as usual with sdist

We could also add a --test flag that would unpack the tarball and attempt to build it (and if it has a test stanza, test it).

We could then add a new command, say updist that by default in order would cabal sdist --test; cabal sdist --vcs; cabal sdist; cabal upload, perhaps with flags to omit workflow steps. Not by default, but optionally it could have a flag to build and upload haddocks as well.

This is just quality of life, but I think it would make things much nicer, as the steps are all so mechanical, and always the same.

[angerman]

Arriving here from the discussion from: https://twitter.com/sclv/status/955706708181110784

If we have some 3rd party token support in hackage, we could build a service that does this for
hosted repos (with webhook support) automatically based on some predefined release/<version>
tag scheme.

Hackage-Upload-As-A-Service. HUAAS!

[23Skidoo]

Sounds like a good idea. One problem is that we don't currently have exactprint for .cabal files, so maybe we can initially just verify that the this tag field has correct info (either v$VERSION or package-name-v$VERSION, where $VERSION corresponds to the value in the version field) and use it to run git tag?

[gbaz]

what's the ticket/status on exactprint? In general good cabal file update automation would be a huge boon. (For local modifications it also could be that we could kludge something simpler but still safe).

[23Skidoo]

#2460 is one of the relevant tickets. @phadej is the one to talk to about this stuff.

[ivan-m]

Tag the branch, update the cabal file to point to the correct tag (using the sadly underused tag field component of the repo field), and push.

This assumes that people tag using pure versions; I've seen some that use formats like v1.2.3, etc.

Also, what happens if people just want the repository field in their .cabal file to point to HEAD? Or have multiple such fields (one HEAD, one to the tag for the branch)?

[23Skidoo]

I've seen some that use formats like v1.2.3, etc.

In simple cases like this where tag format is basically $prefix$version, it should be easy to figure out the prefix by looking at the previous value of this tag.

Or have multiple such fields (one HEAD, one to the tag for the branch)?

Yep, check the docs for the source-repository stanza:

https://www.haskell.org/cabal/users-guide/developing-packages.html#pkg-section-source-repository-source-repository

[gbaz]

My take is we should hardcode a common opinionated default for the tag. We could also extend this to accept some format specification in the future. I think most people are sort of bad/lazy about tagging and about this field, and one purpose of this feature would be to help encourage both...

[quasicomputational]

A useful first step here might be just to add an --upload (and --upload --publish, I guess, if the shorter command only produces candidates) to new-sdist. I strongly suspect that a big, big majority of tarball creation is solely for uploading to Hackage, and that things that weren't produced by sdist immediately prior are very rarely used with cabal upload.

The VCS integration side is also unblocked now that there's reliable printing of .cabal files, though I think it makes more sense to prototype that in a separate tool first.

[hvr]

I feel like this ticket overlaps/conflicts with #3837 which attempts to pay attention to the larger picture and trying to come up with a consistent UI which makes sense.

PS:

The VCS integration side is also unblocked now that there's reliable printing

I'm afraid that's not the case yet

[gbaz]

i mean i think it just complements it/extends the discussion about what steps could be included in such a workflow (bearing in mind they also should share a consistent UI). I.e. that ticket discusses a workflow for the sdist, test, and upload phases, but not the "optionally tag and upload to a vcs" element.