ttc-1.5 out of bounds

[mihaimaruseac]

ttc-1.5.0.0 (changelog) (Travis Cardwell [email protected] @TravisCardwell) is out of bounds for:

• literatex-0.3.0.0 (>=0.4 && < 1.5). Travis Cardwell [email protected] @TravisCardwell. Used by: library

Will place an upper bound.

[TravisCardwell]

Thank you! I just released literatex-0.4.0.0 with support for ttc-1.5.0.0.

TTC is also a dependency of queue-sheet, which has been held back for a long time by ginger. I have been made a co-maintainer of ginger and should be able to catch back up.

I made a Hackage revision to ginger last month, bumping dependency bounds so that it builds with GHC 9.8 and 9.10, but I still am not seeing the bumped bounds via Stack. The bounds in the following error message are the old bounds, not the revised bounds.

In the dependencies for ginger-0.10.5.2:
  * bytestring must match >=0.10.8.2 && <0.12, but bytestring-0.12.1.0 is in the Stack
    configuration (latest matching version is 0.11.5.4).
  * text must match >=1.2.3.1 && <2.1, but text-2.1.1 is in the Stack configuration
    (latest matching version is 2.0.2).

I am certain that Stack is using a very recent snapshot of Hackage, as I saw the logs when bumping/testing the new TTC release.

What am I missing? If you have any suggestions, I would be very happy to hear them. Thanks again!

[mihaimaruseac]

Thank you.

I'll debu the ginger issue, it doesn't look like it is different from Hackage though: https://www.stackage.org/nightly-2025-01-02/package/ginger-0.10.5.2 lists the same revision.

[mihaimaruseac]

Also, in ginger deps I see it is using only the package versions from Stackage.

Do you get the error with the bounds locally only? Can you try on a fresh clone of the ginger repo in a new directory?

[mihaimaruseac]

Just tried and it looks like queue-sheet can actually be added back now.

Actually, no, I spoke too soon. Debugging after current nightly posts.

[TravisCardwell]

I just figured it out! In the nightly link that you included above, I see that the version specifies a revision using 0.10.5.2@rev:1 syntax. That is new to me. By changing the extra-deps in my current configuration to use that syntax, it now builds fine.

Now that I can test queue-sheet with Stack, I will update the dependency bounds. ginger will likely be added to the next LTS snapshot, and queue-sheet will likely be added to that snapshot or a subsequent one, depending on timing. (Note that GHC 9.12.1 is currently blocked by aeson.)

Thank you very much for the assistance. I really appreciate it.

---

My draft reply before figuring it out:

Indeed, I get the error even though everything looks fine. I have only seen the error locally, as I have not committed/pushed with the error.

I went ahead and cleared my ~/.stack, keeping only configuration, and I still get the error.

I just made a fresh clone of ginger and was able to build with Stack without issue using lts-23.2 (GHC 9.8.4) and nightly-2025-01-02 (GHC 9.10.1).

Thank you for pointing out that ginger is now back in nightly! I just confirmed that queue-sheet builds with nightly (after bumping the dependency upper bounds).

The issue seems to only be with the GHC 9.8.4 LTS snapshots. Here is my current configuration:

resolver: lts-23.2

packages:
  - .

flags:
  aeson:
    ordered-keymap: false
  queue-sheet:
    optparse-applicative_ge_0_18: true

extra-deps:
  - ginger-0.10.5.2

The extra-deps is currently required since ginger is not in the GHC 9.8.4 LTS snapshots yet. I will remove it when ginger is added, and perhaps then it will build fine.

[mihaimaruseac]

That's awesome. With this I also TIL that revisions need to be fully specified in extra-deps. Thank you!

[mihaimaruseac]

I got confused by queue-sheet because I ran the check before I pushed the commit testing it, my bad.

When queue-sheet is fixed, we only need to revert 8d55072

[TravisCardwell]

I had an API change, so I released queue-sheet-0.8.0.0 instead of making a Hackage revision.

Regarding specifying the revision, the extra-deps documentation indicates that the "latest revision of a package in the package index (Hackage)" is used. Perhaps my celebration of understanding was premature (or the behavior is changed or the documentation is wrong).

[mihaimaruseac]

There's still one more bound that needs to change:

optparse-applicative-0.18.1.0 (changelog) (Grandfathered dependencies) is out of bounds for:

• queue-sheet-0.8.0.0 (>=0.15.1 && < 0.18). Travis Cardwell [email protected] @TravisCardwell. Used by: executable

[TravisCardwell]

Since optparse-applicative switched from ansi-wl-pprint to prettyprinter, the dependencies to install depend on the version of optparse-applicative that is selected. Flag optparse-applicative_ge_0_18 is used to select the needed dependencies. Cabal makes the selection automatically, but Stack does not, so the flag was set here. The setting for queue-sheet now appears to be missing, however.

A flag was used to select the newer version so that the default would use the older version, which was used in Stackage snapshots at the time. Now that time has passed, I could change the condition so that the newer version is used by default, after which no flags would need to be configured in build-constraints.yaml.

If that sounds good, I can go ahead and make the change for queue-sheet this weekend. I can then make the change for the other packages when I find the time in the (near) future, submitting PR(s) for the removal of the flag configuration in build-constraints.yaml.

[mihaimaruseac]

That sounds good to me, thank you.

I think we removed the flag once the package got dropped. There is also #7438 related to using flags on Stackage: the setting is global to all users of Stackage.

[TravisCardwell]

I released queue-sheet-0.8.0.1 with flag optparse-applicative_ge_0_18 set to true by default. This should resolve the optparse-applicative bounds issue.

I will do the same for the other projects that use this flag in the near future. Since only the default is changed, the current flag settings in build-constraints.yaml are not problematic. I plan on making a single PR to remove them all, after they have been changed for all projects.

Thanks again!

[mihaimaruseac]

That's awesome. Thank you!