I think it depends if we want to support Cabal or other Cabal based workflows like Nix.

If we are going this route, we should check that stack sdist (or whatever command it is that generates a source distribution) does include the cabal file still. Then cabal-install users will still be able to compile if they get the code from hackage. They just won't be able to build it if they get it straight from the repo (they'd have to either use stack or install hpack separately and run it on our package.yaml file).

However I don't think hpack is really doing all that much for us so I'd prefer to stop using it, personally.

The main thing I like about hpack is it fixes the obnoxious globbing in the cabal file, so it picks up updated stuff under examples.

One option could be to add something to the build script that complains if after running hpack the .cabal file has changed? That way you get the best of both worlds, changing one without updating the other will become a build error, and for people who are using hpack they won't have to remember to faff around with the globs ever time the tests are updated.

I agree, that is very nice. It's just that the way I see it, using hpack seems to introduce other issues which are a bit more of a faff than the original issue of having to change the globs for test files whenever you add a new directory.

Unfortunately hpack leaves a notice in the generated cabal file saying what version it is, so I expect we'd get quite a few false positives if we had the build script complain about them not matching.

I actually tried to make cabal's globbing mechanism a bit more sensible a while back, but my PR was rejected because they were worried it would lead people to include files they didn't intend to. I wonder if they might reconsider that now that hpack seems to be catching on...

Unfortunately hpack leaves a notice in the generated cabal file saying what version it is, so I expect we'd get quite a few false positives if we had the build script complain about them not matching.

Ah right, good point!

I'll close this then, as it seems more likely we'll drop hpack than commit to it fully from the preferences you and Phil expressed.

Are we in agreement that we should drop hpack then? I think it would be good to make a decision now while it's fresh in our minds. /cc @kritzcreek

To be clear, the way I see it, the best two options available are: a) remove package.yaml, b) keep package.yaml and remove purescript.cabal from the repo (i.e. what's in this PR). I'm in favour of a) over b) but only just; I'd still be happy with b). I think b) is significantly better than what we have now.

I just checked and stack sdist does indeed include purescript.cabal in the generated source distribution so if we did go for b) we'd only be adding an extra step for people who want to clone the repo and use cabal-install; people who obtained the code from hackage and compiled it using cabal-install wouldn't need to change their workflow.

I'd prefer to continue using hpack and remove the .cabal file from the repository instead. The globbing for tests under examples is super annoying, because the earliest time it fails is on the dist CI build.

Another thing that annoyed me with our handwritten cabal file is how the library and executable/test sections repeat dependencies and you needed to check every section to find out which had the tightest bounds. With hpack the shared dependencies are only listed and bounded once.

Since the version of hpack stack uses is decided by the resolver and we're already saying that the proper way to build binaries is to use the resolver specified in the repo the script that would diff the cabal file on the CI shouldn't ever get into trouble because of the version line, right? As a cabal user you'd just have to use the hpack version from your sandbox for the purescript repo.

I wasn't aware that the version of hpack that stack uses is decided by the resolver. That should indeed make it less brittle.

However I'd rather just remove purescript.cabal from the repo than start messing about with the CI script. In fact having just checked and learned that stack sdist includes the cabal file in the source distribution, even if the cabal file doesn't exist in the repo at the time you run stack sdist, I'm happier with removing the cabal file from the repo. I think it's reasonable to ask people who want to use cabal-install or Nix to either obtain our code from Hackage (in which case they will get the cabal file automatically) or use hpack themselves.

Reopening then as this isn't so settled 😄

This has of course broken the Homebrew build since we build purescript in a cabal sandbox from the GitHub source archive tarball. I tried switching to the Hackage tarball, but it doesn't include the scripts directory, so that leaves us with the option of installing hpack, which significantly increases build time, depending on Stack, which some users will likely complain about since they will have already installed Stack outside of Homebrew, manually writing out the scripts on our own (possible, but not ideal), or fetching the source archive tarball in addition to the Hackage tarball, and plucking out that directory.

Needless to say, it would be helpful if the scripts directory were included in the Hackage tarball.

Do you know if users are relying on the scripts? I ask because the vast
majority of the time, people are not using these executables directly, but via tooling such as pulp, and the tooling has all been updated to use the purs executable now. I think the best option might be to stop providing the scripts, although I suppose it's not ideal to change that during a minor release. I don't think npm install purescript ever gave you the scripts, just as a data point.

I suppose the best approach is to add the scripts to the Hackage tarball for now and remove them all in the next breaking release.

Yes, hence:
Homebrew/homebrew-core#11778
Homebrew/homebrew-core#11779

But we could of course tell them the scripts are deprecated.

For now, I can build from the GitHub source archive tarball, and then pluck the cabal file out of the Hackage tarball:

  def install
    inreplace (buildpath/"scripts").children, /^purs /, "#{bin}/purs "
    bin.install (buildpath/"scripts").children

    cabal_sandbox do
      if build.head?
        cabal_install "hpack"
        system "./.cabal-sandbox/bin/hpack"
      else
        system "cabal", "get", "purescript-#{version}"
        mv "purescript-#{version}/purescript.cabal", "."
      end
      install_cabal_package :using => ["alex", "happy"]
    end
  end

@hdgarrood I've asked @FranklinChen whether he uses the scripts directly or only via tooling here: Homebrew/homebrew-core#11778 (comment)

the option of installing hpack, which significantly increases build time

Just to quantify that, it's 12 minutes 23 seconds vs. 9 minutes 21 seconds.

Ok, thanks - come to think of it, I don't want to expend too much energy on this, so let's just say we'll put them in in 0.11.7 (if there is one) and then remove them in the next breaking release?

@hdgarrood sounds good to me. We have 🍏 on Homebrew/homebrew-core#15513 now, so I'll ship it as-is :)

0.11.6 now shipped in Homebrew.

@ilovezfs one thing I just noticed, actually - do you know if purescript is being built with the RELEASE flag in the homebrew formula? If not, the output of purs --version will be slightly less than ideal:

$ purs --version
0.11.6 [development build; commit: UNKNOWN]

as opposed to

$ purs --version
0.11.6

when built with the flag. I don't have a mac so I can't test, but I thought I might just mention it since you're here.

iMac-TMP:~ joe$ purs --version
0.11.6 [development build; commit: UNKNOWN]

How would I set the RELEASE flag?

I think with cabal-install it would be cabal configure -frelease, see https://www.haskell.org/cabal/users-guide/installing-packages.html#controlling-flag-assignments

@hdgarrood ah ok. Then we can do

install_cabal_package "-f release", :using => ["alex", "happy"]

or

install_cabal_package :using => ["alex", "happy"], :flags => ["release"]

@hdgarrood so @FranklinChen reports, "I don't use them directly, only through Pulp currently."

So I'm not sure whether or not Pulp has been updated yet so that it doesn't need the scripts anymore, but your guess that they were being used indirectly was correct.

Ok, good to know, thanks! There was a short period of time after the release in which all the tools were consolidated into one executable where Pulp hadn't been updated, but that didn't last too long; Pulp was updated quite a while back.

Stack apparently now recommends that the cabal file isn't gitignored, and shows a deprecated warning. I hit a separate issue with this on purescript-native (andyarvanitis/purescript-native#72) when switching between branches that generate differently named cabal files, so I'm going to submit a pr to that project to un-gitignore those files, but the warning itself actually comes from the git dependency on this project. Can I do a similar pr to this repo, seeing as the tides have turned against gitignoring generated cabal files?

@joprice I wouldn’t recommend it, as I’ve done this already, in #3933

Oh nice. That will fix it once that's merged.

I also dropped hpack for personal projects, using the pragma cabal-fmt: expand from https://github.com/phadej/cabal-fmt to generate other-modules and exposed-modules.

If ignoring the Cabal files is generating downstream noise, maybe we should split that part out from the rest of #3933 and expedite it? I don't know how much more deliberation the rest of #3933 needs, but if the answer is more than zero deliberation, unignoring the Cabal files is beneficial and probably uncontroversial.

Unfortunately it’s not uncontroversial: having a non-ignored Cabal file together with a package.yaml file sucks, because people end up modifying the cabal file directly when submitting the PRs (when it needs to be generated from the package.yaml file).