Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bos opened this issue May 24, 2012 · 4 comments
Closed

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

bos opened this issue May 24, 2012 · 4 comments

Comments

@bos
Copy link
Contributor

bos commented May 24, 2012

(Imported from Trac #42, reported by @SyntaxPolice on 2006-01-09)

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
@bos
Copy link
Contributor Author

bos commented May 24, 2012

(Imported comment by @dcoutts on 2006-01-09)

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.

@bos
Copy link
Contributor Author

bos commented May 24, 2012

(Imported comment by @dcoutts on 2008-01-17)

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.

@bos
Copy link
Contributor Author

bos commented May 24, 2012

(Imported comment by @dcoutts on 2008-08-15)

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.

@tibbe
Copy link
Member

tibbe commented May 5, 2014

Closing as there's been no activity in years.

We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.

@tibbe tibbe closed this as completed May 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants