Ticket #42 (new enhancement)

Opened 7 years ago

Last modified 4 years ago

make hugs, nhc, lhc and Cabal agree on installed package info

Reported by: ijones Owned by: ross@…
Priority: normal Milestone: _|_
Component: Cabal library Version:
Severity: normal Keywords:
Cc: Difficulty: hard (< 1 day)
GHC Version: 6.2.2 Platform:

Description (last modified by ijones) (diff)

A pretty simple approach:

The package database is a list, mapping package names to directories. Maybe the gentoo folks and others would be happier if it's a directory where each file name is a package name and the content of that file is a directory to find the source for this package.

If we go the "don't alter hugs" route, we'd need a wrapper around hugs (maybe cabal) to read this file and add the -i flags to the hugs command-line.

So this could be implemented outside of hugs, with just cabal and hugs-pkg, then we could include a concept of a package database in the cabal interface to make toast / gentoo happy. In fact, we could do all that in Cabal without a hugs-pkg.

Of course, it would be nice if someone could say ":package foo" on the Hugs command-line, but that's not completely necessary. We could punt on that until we get more clear about the role of packages in the language.

When implementing this, be sure to add

  1. register step to cabal (register in hugs a little bit of something)
  2. hugs-pkg as a package tool
  3. command-line args to hugs or hugsWrap relating to the packages

Problems with not having hugs-pkg

  1. no way to tell hugs to turn packages on / off
  2. register / unregister don't make much sense
  3. no way to install into a non-standard location and expect hugs to find the package

Change History

Changed 7 years ago by ijones

  • description modified (diff)

Changed 5 years ago by duncan

  • ghcversion set to 6.2.2

We install the InstalledPackageInfo with each package (I didn't know that, but apparently we do). So in theory all we need to do is read those files back in and we have a package database.

Of course it would be better if hugs came with the package registration files for all the core packages.

Changed 5 years ago by duncan

  • owner set to ross@…

So I'm happy with the idea that for hugs and nhc that we do not need a distinct concept of a package database. The package database can coincide with the location where packages are installed, and hugs/nhc just look in that dir for their packages. Cabal would also look there for the InstalledPackageInfo files. So the package db and the libdir are really the same thing.

Hugs already looks in ~/lib/hugs/* for package directories.

So for hugs there are two things to do:

  • make Cabal and hugs agree on where the per-user install path for package should be. Currently cabal-install puts them in ~/.cabal/lib/hugs/* (or something like that).
  • get the next release of hugs to include the InstalledPackageInfo files for all the packages that it comes with. This will enable cabal to know what packages are installed by reading these files, just as it does with ghc by asking ghc-pkg for the equivalent info.

I'm not sure which of Hugs or Cabal should change on the issue of where packages are instelled per-user. I know people would scream if cabal installed things in ~/lib by default, but perhaps if they're using hugs then they don't care. If we have to get hugs to change anyway to include the InstalledPackageInfo files then adding an extra default search path entry for a location under ~/.cabal/ would not be any more work.

Changed 4 years ago by duncan

  • difficulty changed from normal to hard (< 1 day)
  • summary changed from implement hugs-pkg? to make hugs, nhc, lhc and Cabal agree on installed package info
  • milestone set to _|_

This isn't tht hard but needs changes in Hugs and a bit in Cabal and then testing and a new hugs release. The scheme with installed package info files should work for hugs, nhc and lhc. On the Cabal side of things the same implementation can be used for each.

Note: See TracTickets for help on using tickets.