Ticket #42 (new enhancement)

Opened 3 years ago

Last modified 4 months ago

implement hugs-pkg?

Reported by: ijones Assigned to: ross@soi.city.ac.uk
Priority: normal Milestone:
Component: Cabal library Version:
Severity: normal Keywords:
Cc: Difficulty: normal
GHC Version: 6.2.2 Platform:

Description (Last modified by ijones)

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

01/08/06 21:52:28 changed by ijones

  • description changed.

01/17/08 11:44:55 changed by duncan

  • platform changed.
  • 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.

08/15/08 07:08:02 changed by duncan

  • owner set to ross@soi.city.ac.uk.

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.