Change:
setBuildTarget = callPackage ./setBuildTarget { }; writers = callPackage ./writers { }; incremental = callPackage ./incremental { }; <ins> upstreamStackHpackVersion = callPackage ./upstreamStackHpackVersion { }; </ins> }

Discussion:
The that's currently in nixpkgs uses , the official stack binary release uses For more details, I think the core issue is basically the same as I think the fix is to change the version of which the in nixpkgs is built with from (which is the version of the package in nixpkgs) to .
It would also be great to have some automation to make sure this doesn't regress. I guess that would involve downloading an official matching version stack binary and checking what the version is there (via ), if there is no better way to get the upstream hpack version.
In what way does this issue present? Supposedly stack has become more resistant to this problem: It seems ridiculous that we'd have to track what stack binaries ship for all eternity.
The concrete issue is that get stack from colleagues get stack from the official bindist add new source files run file gets regenerated to include the newer files, but also potentially other changes happen, because my hpack version is different (at the very least, the hpack version comment changes) commit the file, as recommended by the issue you linked my colleague pulls in my changes, they use an official stack release with a different hpack version, so they get arbitrary issues, depending on the different version. At the very least they get some weird mismatch, or the file doesn't get regenerated, etc. I don't really understand this - for dev facing tools, isn't it expected that would track the official releases? Otherwise this introduces reproducibility issues between getting your tools from and from official releases, hence I am now arbitrarily going to get breakage if I choose to use NixOS when collaborating with non-NixOS users (or I have to potentially apply some workarounds to be able to use official releases because official releases don't always work on NixOS).
But the real problem here is not an incompatibility between stack and hpack versions. It is like with very many tools, that you using another hpack version than your coworkers does not work. I am uncertain what the best solution for that is. But in general nixpkgs downgrading software because other distribution methods are not as fast is a bit unsatisfying. Additionally, I find it mighty confusing, that the stack binaries are not build with hpack version from stackage.

Using the hpack version from stackage LTS, which we do, is the most blessing one can generally achieve for a package version. So all of this is me shouting like a five year old: “Not our fault!” The question is what to do about it. Have you considered using an older nixpkgs version which uses the right hpack version? Apparently the whole process is super sensitive to the hpack version, so if we downgrade hpack now we probably annoy other people. If there is no better solution maybe we need to supply different hpack versions and stack with different hpack versions and the user can choose?
I agree I agree I would guess that if you bless the version that the official stack bindist ships, nobody would complain, except maybe a single instance of other nixpkgs stack users, after which it should be fine? I guess a more principled approach would be to instead live with this for now and wait until stack bindists bump hpack version, at which point start tracking the hpack version provided with bindists. Of course I can work (and actively am working) around this. And also I do not expect that miraculously software from nixpkgs will be bug for bug compatible with official bindists. But this feels like a relatively simple(perhaps? I do not know how easy it is to have an additional version in nixpkgs) change to make, which results in actual observable incompatibility being reduced.
In the past we have overridden the version of used by to work around this issue. Just like is saying, it is very annoying to use from Nixpkgs with a team of people who otherwise get stack from upstream. I guess a newer hpack version was recently released and it slipped through. would you be able to send a PR overriding the hpack version used by stack so that it is in sync with upstream? If you could figure out a simple test to add in , that would be ideal as well.
I've created to adding a test. However, that requires an internet connection, and from what I understand, nixpkgs tests run in a sandbox, and that won't be available(?)

Should I: somehow allow connection to the stack official bindist urls in CI (not sure how to do this) instead manually hardcode a mapping , which must have an entry for the stack version that's currently in nixpkgs, i.e. when a new stack version comes in, whoever is doing updates will be forced to update the mapping (not sure where to do this either) Additionally, I couldn't find how to make build with a specific version of - could you give me a pointer to where I could see an example/read up on this? Currently has , but I don't seem to understand where that is used explicitly (if it is at all).
That's correct. I like what you currently have in your commit, but you'll have to pin the upstream (non-nixpkgs) stack version with a commit hash (and ideally fetch it with something like or or something). Ideally you'd be able to write it so that when the stack version is bumped in Nixpkgs, the test will automatically start failing. Also, could you add yourself as a maintainer to the test, so that you'll be pinged when it starts failing? That would help with the maintenance of the test. A lot of these types of overrides are in . Here's an example of overriding the version of a direct dependency for a package: You'll likely have to do something similar for hpack with stack.
Currently / provides stack-2.9.1 as the top-level attribute (even though the latest release of is 2.9.3), and it uses hpack-0.35.2. Upstream uses the following hpack versions: stack-2.9.1: hpack-0.35.0 stack-2.9.3: hpack-0.35.1 I've just pushed in , which drops 's hpack dependency to 0.35.0, in-line with upstream . This should make sure people getting from Nixpkgs use a compatible version with people that get stack from upstream. I'm going to keep this issue open in case anyone is able to send a PR implementing some sort of test in Nixpkgs that upstream stack and our stack use the same hpack version.

Just so I understand this right: If someone's team uses “stack-2.9.3: hpack-0.35.1” but they themselves get our “stack-2.9.1: hpack-0.35.0” do they still have this problem?
Thanks and sorry for not getting back to this earlier. I'll still have in mind trying to write a test for this. It did somehow become an issue for my workplace, because this causes the original issue but in reverse - I was using a newer hpack(from nix) and someone was using the older one, causing some kind of issues for the other person. However, I currently can't dig out the exact complaints.
My understanding is that this is correct. If you're using + in a team setting, you have to make sure everyone uses the same version of , compiled with the same version of . (Although it might be the case that you only have to make sure the version is the same, you don't all necessarily have to use the same version of .)
What's the state of this issue?
I fixed the underlying problem in . But we don't have any assurance that the same problem won't crop up again the next time Stack releases a new version. I was leaving this issue open so that hopefully someone would send a PR adding some sort of test that the hpack version used by Stack in Nixpkgs is the same as the hpack version used by the upstream Stack release. Although I don't have a good idea of how to write this test in such a way that we won't have to manually bump a version/URL/hash every time there is a new release of Stack, which is quite annoying. It is the git-annex problem all over again.
I implemented the check for the upstream stack/hpack version in