PureScript v0.14.7 released

Announcements
#1

PureScript v0.14.7 has been released! This would have been the v0.14.6 release, but I didn’t bump a dependency correctly. So, please ignore v0.14.6.

A v0.14.7 package set hasn’t yet been released but the latest v0.14.5 package set works. A v0.14.7 package set should be released in the next few days.

It’s hard to determine which changes to highlight in this release, so I’ll defer to the release notes. That being said, this release is the last release in the v0.14.x series. The next release v0.15.0 will support ES modules.

Thank you all who contributed!

Full release notes below:

16 Likes
#2

Thank you all for your great work!

I noticed that this one is build from source if I install it via npm on my system (Linux) and to be honest I have no clue how the releases work.
Is this to be expected of does it just take a while for the binary packages to be available?

#3

In case you need a Docker image, I have already built one, and made it available on hub.docker.com:
Docker PureScript 0.14.7 image.

For some reasons, it required the legacy (at least for Debian Buster) libtinfo5 library, so it is also installed in the image. (And that’s the reason I gave the link to the image, since normal installation of PS binary failed without the libtinfo5 library.)

1 Like
#4

Huh… That’s odd. I believe the installer attempts to download the binary from the GitHub release page and if that fails it compiles it from source.

#5

Hello thanks for the reply - that’s what did happen to me before.

On my Windows machine at work if did install the binariers - so maybe it’s either some timing issue or something on my Linux setup caused a mismatch.

Sadly I did not enable verbose logging on npm install so I don’t exactly know what happened (at first I thought the command hanged so I interrupted it and saw that it was compiling in the background - I then just opted to redo the command and let it compile for a few minutes …).

I’ll try to find the script and see what could have been the problem.

I used to lack some dependency on an outdated Linux Mint 18 system and have switched to Manjaro stable for a while and Manjaro had a stable-release yesterday too … maybe now some dependency is to new :wink:

#6

Just FYI. The v0.14.7 package set has now been released.

#7

Is there a rough estimate about when can the 0.15 release land?

1 Like
#8

The short answer is, “Any estimate I give you will likely be wrong because I don’t know. It’ll be ready when it’s ready.”

The long answer is…
When we made the v0.14.x ecosystem update, it took about 5-6 months. I think we started around October 2020 and finished late Feb 2021. There are a couple of reasons for why things took so long:

  • a lot of breaking changes had been pending for a while, so we paid off a lot of technical debt. However, that broke a lot of code
  • Travis CI did its thing, so we had to migrate all repos to GH Actions, which not all were familiar with as of yet
  • Even after much review, a few bugs in the Coercible PR still got through, and we had to re-update some of the same repos to fix that once the actual compiler bug got fixed
  • all core libraries need at least 2 approvals (if contributor is not core team member) or 1 approval (if is core team member), and getting approvals was often a bottleneck during the holiday season

In this breaking change release, I don’t think we’ll be merging as many breaking changes in repos. The significant feature is ES modules, so the less breakage and discussion we have, the sooner we can get it shipped.

#9

I noticed that this one is build from source if I install it via npm on my system (Linux) and to be honest I have no clue how the releases work.
Is this to be expected of does it just take a while for the binary packages to be available?

The prebuilt linux binaries can only be used on glibc-based distributions (which rules out, eg, Alpine) and we only provide x86_64 binaries, so if you’re on a non-glibc distro or an arch other than x86_64 you’ll need to build from source. A network failure would probably also explain that behaviour though.

#10

For some reasons, it required the legacy (at least for Debian Buster) libtinfo5 library, so it is also installed in the image. (And that’s the reason I gave the link to the image, since normal installation of PS binary failed without the libtinfo5 library.)

This shouldn’t be necessary any more. Are you building the compiler with cabal? If you build the compiler with stack then you should automatically end up with a binary that doesn’t depend on libtinfo.

#11

No, I’m not building the compiler. I’m installing it using precompiled binaries from github repo, with npm.

AFAIK, the installation procedure is simple: (1) download the binary from github, then (2) test the binaries. The second step failed in my Docker Debian-based image, and I had to install the legacy libtinfo5 library for the test to pass.

Not a big problem, though, just an interesting situation. The legacy libtinfo5 library wasn’t needed for 14.5, nor for 14.4.

#12

Thanks for letting me know. This is definitely a bug and we should fix it. I’ll write up a report.

Edit: https://github.com/purescript/purescript/issues/4253

#13

Hi - thanks for your answer.

I could not reproduce the issue so I guess it was some kind of network problem.

1 Like