search

fpco / stackage-cli

MIT License
28 stars 4 forks source link

stackage-purge #5

Closed chrisdone closed 9 years ago

chrisdone commented 9 years ago

Plugin executable to clear the package database (should detect sandbox) and the cabal.config file. Should prompt the user (but can be overriden with --force) with some useful display like "cabal.config will be removed" and perhaps "x hundred packages will be removed from database foo/bar." It can either unregister the packages one by one or drop the database and init it again in-place. This is for when a user is doing an upgrade or screwed up. But be sure to make it require an extra step lest someone run it by accident.

DanBurton commented 9 years ago
DanBurton commented 9 years ago
chrisdone commented 9 years ago

This seems to work nicely.

I think it should detect the user database as a potential place to remove packages for those people not using sandboxes (after all, they're less important when hacking against a stackage snapshot), whereas the global db probably never changes.

DanBurton commented 9 years ago

Should prompt per-database if the user wants to purge that package database.

DanBurton commented 9 years ago

I didn't implement purge sandbox package database? [default yes]. It was easier to leave the default as "no" for all interactions, which I think is still a reasonable default for now. (--force is the same as answering yes to all interactions.)

I believe this issue is ready to close.

chrisdone commented 9 years ago

So to clarify:

  1. stackage purge in a sandbox only prompts to purge from the sandbox database.
  2. stackage purge outside of a sandbox prompts to purge from the global and user databases.

Example:

chris@retina:~/Work$ stackage-cli/.cabal-sandbox/bin/stackage-purge (Global) /opt/ghc/7.8.4/lib/ghc-7.8.4/package.conf.d Detected 29 packages to purge from this database Unregister 29 packages (y/n)? [default: n] /home/chris/.ghc/x86_64-linux-7.8.4/package.conf.d Detected 1 package to purge from this database basic-lens-0.0.0 Unregister 1 package (y/n)? [default: n] chris@retina:~/Work$ cd stackage-cli chris@retina:~/Work/stackage-cli$ ./.cabal-sandbox/bin/stackage-purge (Sandbox) /home/chris/Work/stackage-cli/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d Detected 49 packages to purge from this database Unregister 49 packages (y/n)? [default: n] chris@retina:~/Work/stackage-cli$

This deviates from what was written above but I'm fine with this behaviour.

DanBurton commented 9 years ago

Cool. The behavior is simply based on whatever ghc-pkg lists. If a sandbox db is detected (via inspecting cabal.sandbox.config), then the --package-db arg is used with that sandbox, for both the list and unregister commands.

There's another example -- the thing I was trying to explain about hsenv -- where both the Global and Sandbox databases are listed in the ghc-pkg output, so both are prompted for.

[hsenv]bash> stackage purge
(Global) /home/dan/hsenvs/ghc-7.8.4/lts-1.14/.hsenv/ghc_pkg_db
Detected 232 packages to purge from this database
Unregister 232 packages (y/n)? [default: n] 
(Sandbox) /home/dan/github/fpco/stackage-cli/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d
Detected 46 packages to purge from this database
Unregister 46 packages (y/n)? [default: n]

It's presumably very unusual to have both an hsenv and a sandbox, so I'm not too worried about this use case. In any event, it's always entirely clear which db will be affected.

DanBurton commented 9 years ago

then the --package-db arg is used with that sandbox, for both the list and unregister commands.

I misspoke; the --package-db arg for the unregister command matches the corresponding prompt.