2

I am working on a Haskell package. I have not yet uploaded it to Hackage and the version number is 0.1.0.0. I am using new style Cabal commands.

In order to test the package while I'm working on it (to make the library available to the test project), I run cabal new-install --lib after building the package.

However, I noticed that bug fixes were not having any effect and my test project (which is not itself a Cabal project and consists of a single Haskell file) continues to behave the same way even when I build and install the library.

So, I've tried modifying the cabal new-install --lib command with various combinations of flags like --force, --force-reinstalls and --reinstall. This did not have any effect.

Neither did deleting all generated files in both the library and the test project and re-building the library before recompiling the test project.

One possible solution might be to increase the version number. However, since the package is not released yet, I do not want to start using up version numbers before I upload it to Hackage. Even after I release it, I would like to change the version number only when I actually upload the new version to Hackage, not every time I test out a minor change on my own PC.

The old Cabal commands behave just fine. However, is there any way to get new-install to reinstall the package whenever I fix a bug without changing the version number?

I found a bug report from 2012 that might be relevant but I must admit that I do not understand it very well since I'm completely new to Cabal. https://github.com/haskell/cabal/issues/294

Liisi
  • 329
  • 1
  • 6
  • I have tried to reproduce this with cabal-install 3.2.0.0, and got a different result. After changing the library and using `cabal install --lib` a second time to reinstall it, trying to use the standalone test file led to an "Ambiguous module name" failure, which can be worked around by manually editing the GHC environment file, as reported and discussed in [Cabal issue #6391](https://github.com/haskell/cabal/issues/6391). (BTW, which cabal-install version are you using? I'm not sure it actually matters, but it's worth noting it just in case.) – duplode Jun 23 '20 at 15:49
  • @duplode I have version 2.4.1.0. – Liisi Jun 23 '20 at 15:57
  • I don't really know if the interaction of cabal-install and GHC environments has changed in some way between 2.4.1.0 and now. Besides upgrading your cabal-install (which can be done independently from the rest of your Haskell setup with `cabal new-install cabal-install`, or through ghcup if you are using that), one possible check would be looking at your default GHC environment file (which should be at `~/.ghc//environments/default`), and, in particular, at how many entries there are for your library before and after trying to change and `cabal new-install --lib` it. – duplode Jun 23 '20 at 16:23
  • @duplode Thank you for the suggestion. I tried to upgrade Cabal but some of the packages failed to install. I'll hopefully be able to see whether the new version solves the problem next week, when I'll have an opportunity to ask for some hands-on help with the upgrade. – Liisi Jun 23 '20 at 17:14
  • @duplode I now have the newest versions of ghc (8.10.1) and Cabal (3.2.0.0). By the way, if it is relevant, I have Windows 10. When I try to cabal new-install --force --global --lib --verbose in the folder where I build my package, I get the following warning: Failed to query pkg-config, Cabal will continue without solving for pkg-config. constraints: Cannot find pkg-config program. The test project can't find the package. I tried installing pkgconfiglite - however, it did not solve the issue, so I uninstalled it again. – Liisi Jun 29 '20 at 18:28
  • C:\Users\Liisi\.ghc\x86_64-mingw32-8.10.1\environments\default does contain the name of my package. In the test project, ghc, ghc --make and ghc -package-env=default --make don't work. The first two can't fing the library, the third one results in "Package environment "default" not found". ghc -package-env=C:\Users\Liisi\.ghc\x86_64-mingw32-8.10.1\environments\default --make does work. However, it is a usability nightmare... – Liisi Jun 29 '20 at 18:31
  • Thanks to your last comment, I *think* I have recalled what is likely causing problems here. Is there any GHC environment file in the directory of the file you are trying to compile? (The file name should be akin to `.ghc.environment.arch-os-version`; I don't know if it is a hidden file in Windows.) Cabal used to create environment files for projects upon running `cabal build`. It hasn't done so by default since 3.0 (because it was causing issues of the sort you describe here), but since you were using 2.4.1.0 it is quite possible that is happening here. – duplode Jun 30 '20 at 00:44
  • I have turned on the option to see hidden files and folders and the test project contains none. Searching for a file name that contains ghc.environment returns no results (neither in the test project nor anywhere else on the whole drive). So I probably don't have it. – Liisi Jun 30 '20 at 16:10
  • How very odd. I find it particularly puzzling that your GHC seemingly can't find the default environment file, so that you have to specify the path manually. – duplode Jul 01 '20 at 01:03

0 Answers0