Please remove the test

[ip1981]

The test is useless and when run automatically it likely fails for reason not related to the package.

See for example: https://github.com/NixOS/nixpkgs/issues/20478

[paul-rouse]

Well, I put it there because I use it to test that building works with various combinations of packages (see the .travis.yml) Can't you simply arrange not to run it if you don't want it?

[ip1981]

Disabling it is not trivial in nixpkgs pinned to specific version. I'd use separate program/flag to run at travis.

[3noch]

@ip1981 haskell.lib.dontCheck ?

[ip1981]

I'm looking for options. dontCheck will require a lot of levels of overrides. Meanwhile the test does not work for most of consumers.

[3noch]

Alternatively you could try to get dontCheck into nixpkgs directly for this package. But I agree that's hacky.

[ip1981]

This works:

# cat modules/pkgs/mywatch/default.nix 
{ haskell, haskellPackages }:

let myHaskellPkgs = haskellPackages.override {
  overrides = self: super: {
    mysql        = haskell.lib.dontCheck super.mysql;
    mysql-simple = haskell.lib.dontCheck super.mysql-simple;
  };
};

in myHaskellPkgs.callPackage ./main.nix { }

But. The test is broken by design :)

[3noch]

Yah I've had to do that with other packages. Not fun. Database packages seem to often require a lot of harness for tests to run.

[paul-rouse]

I think it is unhelpful to say that the "test is broken by design". It is the way it is to make my job easier, and over time it may well be extended to do more functional tests.

That said, I don't mind checking a flag or environment variable to stop the test trying to make a connection, but I would prefer to make the opt out explicit, leaving the default as it is.

[3noch]

@paul-rouse The impedance mismatch is that the nixpkgs ecosystem enables tests for all packages by default. Certainly functional tests that rely on a working PostgreSQL instance, etc. are not easily supported by this design. I'm thinking it would just be better to have nixpkgs disable tests by default for this package.

[paul-rouse]

@3noch Yes, it does feel as if nixpkgs is really the right place - and of course stackage has a similar issue, but there is easy support for ignoring tests in that case. I'd still be happy to incorporate something if it makes life easier/cleaner for nixpkgs, though.

[3noch]

@paul-rouse Anything that's not the "default" will be the same amount of work for nixpkgs because it will have to override.

[3noch]

That said, some tests is better than no tests: if you had some way of disabling functional tests that might be the best.

[kquick]

The current test would make a great example application, as an alternative to a test.

Having tests is great, but this is also going to break if there is an actual mysql server running that doesn't support the test user without a password. Maybe the test should be written to start an alternate mysql server at an unused port and with a pre-set configuration that matches the expectations of the test.

Thank you for maintaining this package (and mysql-simple), Paul!

[paul-rouse]

I am quite keen to keep this as a test, since it may well grow in the future to become more meaningful. I am also keen that a user who hasn't looked at the details, but just says stack test or cabal test, should get a pretty strong indication that they were unable to run the full test.

Now, a "strong indication" doesn't have to be a test failure in the technical sense: I would be happy with a big, fat, unmissable message explaining what needs to be done to run the test in full. Unfortunately, if this message is produced by the test itself, cabal hides it away in a log file unless the test does actually fail (stack does send it to the terminal in reasonable cases, and I am aware of the proposals for a similar default in https://github.com/haskell/cabal/issues/1601 )

Any ideas?

[ghost]

I am stumped on how to get output while keeping the tests passing...

Note: I generally have moved towards three test suites by default. Unit test. Basic integration tests. Extensive integration tests. Extensive integration tests get their own cabal file. The first two are in the main cabal file, with unit tests running by default and basic integration tests running as an opt-in by flag. You could force the basic integration test suite to run on PRs via Travis?

[ghost]

https://hackage.haskell.org/package/gargoyle-postgresql-0.1/src/src/Gargoyle/PostgreSQL.hs - Obsidian recently used this to help Databrary run a database with minimal installation/hassle. I am not sure how much work it would be to port that to mysql, but if it were ported, that might provide some very convenient ways of writing tests that could be run anywhere with little ceremony.