I discovered today that pretty much all current documentation of how to build anything in Halogen is targeting v4.0.0. I’ve gotten past the Bower awkwardness and am using Spago, as is apparently the recommended tool for today. However, I’d like to just “make something work” and the latest Halogen has breaking changes in it. For example, the changes to Halogen.Component.ChildPath, which appears to have completely changed, based on the notes I read for version 5. I’d like to be able to tell Spago to just use the older version of Halogen, for now. However, I can’t find documentation on how to pin a specific package version in spago.dhall anywhere. Can someone point me in the right direction? Thanks.
From my understanding of spago and .dhall files to handle packages, what you want is look into packages.dhall and replace the = between curly braces in let additions = {=} or let overrides = {=}, with something like
let Package =
{ dependencies : List Text -- the list of dependencies of the Package
, repo = Text -- the address of the git repo the Package is at
, version = Text -- git tag
}
Also check the packages.dhall file in your local folder comment which has
## Use Cases
Most will want to do one or both of these options:
1. Override/Patch a package's dependency
2. Add a package not already in the default package set
This file will continue to work whether you use one or both options.
Instructions for each option are explained below.
### Overriding/Patching a package
Purpose:
- Change a package's dependency to a newer/older release than the
default package set's release
- Use your own modified version of some dependency that may
include new API, changed API, removed API by
using your custom git repo of the library rather than
the package set's repo
Hope that points you in the right direction
– hopefully someone with proper experience gets back to you
Good point. To be more precise, you can take any of these steps, in the order that I would take them.
First, you can override the package that you need on a specific version, as I demonstrated with Halogen. Overriding one package only affects that package; all other packages in the set are unchanged.
Second, if overriding one package has now broken another package (or it needs a different version of a dependency), then you can adjust the other packages, too. You’d override each affected package. You’re essentially pinning version numbers for some of your packages.
Third, if too many packages would be affected by a version change, then you probably want to change your entire package set to be an older package set – whatever the latest package set was that contained your package at the version you want. For example, you’d find the last package set that contained Halogen 4, and now you know that it will compile with all the other packages. If you then want newer versions of some packages, you’d rinse & repeat steps 1 and 2.
In practice I’ve never had to override more than a handful of packages to tweak a package set to what I needed; if you find yourself adjusting more than say 5 packages then you might want a different package set.
I was curious how bad it would be to move back to Halogen 4 (the v5 release candidate has been out for about a year), and found its version number in the package-sets repository:
I walked back through the git blame to find when it was moved from v4 to v5, which was as part of this PR:
which is unfortunate, because it means the last time Halogen 4 was in the package sets was when the package set was updated for 0.13 compatibility. Compiler versions are particularly turbulent with multiple packages releasing potentially breaking changes, so moving to Halogen 4 may mean you need to move to this older package set and thus to older versions of a number of libraries.
That pull request corresponds with this package set release:
which means the previous release is the latest one containing Halogen 4 (and libraries that all compile with Halogen 4):
Unfortunately, Halogen 4 might not be compatible with the 0.13 compiler (according to these release notes); that would mean you’d need your project to be using the 0.12.x compiler as well as the older package set.