The package system has a notion of "auto" packages, which are packages that were automatically installed to satisfy dependencies. Also, `raco pkg remove' supports an `--auto' flag for automatically removing auto packages that have no non-auto packages depending on them.
So, instead of adding package roots, one possibility is: * Make `raco pkg show' show only non-auto packages by default. * Change the `pkg-links' Makefile target to install only links for packages needed by a particular package (which defaults to some sort of "main-distribution" package), and to install links forced by dependencies as "auto". The second bullet is along a direction that things are moving, anyway. I think there will need to be some other refinements to auto mode. For example, if you have a package in auto mode and you try to install it, I think you get an already-installed error and the package stays in auto mode. But those are small changes, I think. Does this sound enough like what you had in mind? At Thu, 27 Jun 2013 12:53:59 -0400, Carl Eastlund wrote: > I just ran "raco pkg show" on a fresh install, and its output is huge now. > Of course, this is inevitable when we break the distribution up into many > packages, but it makes the tool unmanageable for routine use. I'd like to > propose a way around this, that would also solve some of my normal > usability gripes with package managers. > > I propose we have "package roots" -- roots to the forest of package > dependencies. These are the packages the user actually wants; every other > installed package is pulled in as the dependencies to support these. Then > "raco pkg show" can show just these packages, so in a fresh install we'd > just see "racket" or "racket+gui" or whatever. We could add a flag to show > everything, when necessary. > > This also gives us some room to automate removal of packages the user > doesn't need. For instance, if I install package A which depends on B, C, > and D, of course raco pkg install will install B, C, and D. If I remove > package A, currently B, C, and D are going to stay unless I explicitly > remove them, if I recall correctly. If we base our system on a set of root > packages, then B, C, and D would be removable as soon as A is removed, if A > was a root and the others were not. We could have "raco pkg remove A" > remove them immediately, or we could have some explicit "raco pkg cleanup" > to remove them. Whichever way we go, we could add a flag to "raco pkg > remove" to swap behavior. This would make cleaning up a lot easier when a > package has many dependencies. It would also mean upgrading a package > whose dependencies have changed would allow the system to automatically > clean up dependencies that aren't needed any more. > > I don't know how hard it would be to implement this, but I think it would > make the package system much more usable to present 90% of the interactions > solely in terms of the top-level packages the user cares about, and do all > the cleanup of dependency packages silently in the background when possible. > > Carl Eastlund > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev
