Is there a way for a package to detect that it's building on hackage?

We have a package (https://github.com/Copilot-Language/copilot/tree/master/copilot-bluespec) that cannot be tested on hackage because bsc (bluespec) is not included.

We could disable tests by default, but I'm wondering if there's a way to disable tests on hackage only, and keep them enabled by default otherwise.

Hackage doesn't build tests, or at least doesn't run themm does it?

Hackage does build and run tests. This can be disabled per-package on hackage: https://hackage.haskell.org/package/copilot-bluespec/maintain

This is however not an ideal situation, as it has to be done for each version. A PR to hackage to allow disabling tests across all versions (including yet-to-be-uploaded) would be welcome.

One can update Hackage configutation to install bluespec by submitting a PR to https://github.com/haskell-infra/hackage-doc-builder-config

@RyanGlScott

Tagging @RyanGlScott .

Hackage does build and run tests.

Interesting. I find that somewhat surprising. I'd prefer running tests to be opt-in, I don't find it useful at all.

I don't want my docs building failing because of test issues (mostly missing compile or run time dependencies)

Addition: test runner should use --test-show-details=direct or always. Hiding the test output is no point in CI

Running 1 test suites...
Test suite smoke: RUNNING...
Test suite smoke: PASS

is useless, especially as that suite probably says that it's skipped (because no external runtime dependency is found), but I cannot be sure as output is omitted.

I don't want my docs building failing because of test issues (mostly missing compile or run time dependencies)

I think it's independent: docs will be built just fine even if tests fail.

Addition: test runner should use --test-show-details=direct or always.

I raised this recently in #1397.

Returning to the original question of how to fix the Hackage tests for copilot-bluespec: I wouldn't mind opening a PR on the hackage-doc-builder-config to add bluespec to the list of packages in build-depends.nix. That being said, I have a question about the scope of build-depends.nix. The top of that file says:

# Packages available to packages built using the Hackage Haddock builder

The key phrase there is "Haddock builder". Is it acceptable to add packages there solely for the sake of running tests? (copilot-bluespec uses bsc in its test suite, but otherwise its Haddocks build without issue.)

@RyanGlScott

@RyanGlScott I don't know that the current setting to disable tests would help us otherwise.

Currently copilot-bluespec is set to not run tests:

However, it still shows that building the tests failed:

Apparently, a re-build (which I tried to trigger last week) does not help.

Is it acceptable to add packages there solely for the sake of running tests?

Any updates on this question?

Hackage does build and run tests. This can be disabled per-package on hackage: https://hackage.haskell.org/package/copilot-bluespec/maintain

This is however not an ideal situation, as it has to be done for each version. A PR to hackage to allow disabling tests across all versions (including yet-to-be-uploaded) would be welcome.

I published a few packages on hackage recently with external dependencies, one even used z3 in tests.
I didn't do anything to disable test and don't remember any issue with failing test.
So Hackage just stores the uploaded archive.
Is building test a special Hackage feature available on request?

@yaitskov

@yaitskov if you upload Haddocks yourself, Hackage recognizes it as a hint not to build the package (or run tests). This is somewhat coincidental: the builder was originally just to build docs and later extended also to run tests, but the old logic "don't bother to build if an author has already provided Haddocks" remains.

Gentle ping.

Adding packages to the nix config for running tests as well as building haddocks should be fine, within reason, imho.

Adding packages to the nix config for running tests as well as building haddocks should be fine, within reason, imho.

Could a hackage-server use nix files from the project?

I nixified the copilot in my fork.

That's not the intention. Rather, the nix config for hackage-builder is to provide third party non-haskell binaries that are necessary for building (and testing as well) packages uploaded to hackage.

That's not the intention. Rather, the nix config for hackage-builder is to provide third party non-haskell binaries that are necessary for building (and testing as well) packages uploaded to hackage.

aha I missed the point that ci works with a archive not a git, but technically as a hack cabal can include a few nix files as extras. The nix config is classic, just master, no flakes, no nix.conf tuning like in cardano-ledger.

then the whole class of such issues wouldn't exist.

I wouldn't mind opening a PR on the hackage-doc-builder-config to add bluespec to the list of packages in build-depends.nix.

I think that'd be a good idea.

What does the Nix config has to do with the initial topic of this issue:

Is there a way for a package to detect that it's building on hackage?

I think it'd be good to address this issue regardless of what is there in the Nix config.

Merge branch 'develop-fix-hackage-tests'. Close #673.

Navigation Menu

Repository navigation

Is there a way for a package to detect that it's building on hackage? #1414

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Is there a way for a package to detect that it's building on hackage? #1414

Description

Activity

phadej commented on Jul 10, 2025

gbaz commented on Jul 10, 2025

Bodigrim commented on Jul 10, 2025

ivanperez-keera commented on Jul 11, 2025

phadej commented on Jul 11, 2025

phadej commented on Jul 11, 2025

Bodigrim commented on Jul 13, 2025

RyanGlScott commented on Jul 14, 2025

ivanperez-keera commented on Jul 14, 2025

ivanperez-keera commented on Sep 17, 2025

yaitskov commented on Nov 15, 2025

Bodigrim commented on Nov 15, 2025

ivanperez-keera commented on Nov 21, 2025

gbaz commented on Nov 21, 2025

yaitskov commented on Nov 21, 2025

gbaz commented on Nov 21, 2025

yaitskov commented on Nov 21, 2025

ivanperez-keera commented on Dec 4, 2025

ulysses4ever commented on Dec 4, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions