Call for Discussion: Specification of package location via configure

"Stephen J. Turnbull" <[email protected]> Wed, 08 Dec 2004 23:08:35 +0900
Newsgroups gmane.emacs.xemacs.beta,gmane.emacs.xemacs.design
Organization Graduate School of Systems and Information Engineering University of Tsukuba
Message-ID <[email protected]>
We're considering simplification of the process of configuring the
location(s) for packages at ./configure time.  Please direct comments
and use cases to XEmacs Design <[email protected]>, and CC Ben
Wing <[email protected]> (Reply-To is set).

We're interested in use cases for specifying package location.  Given
that currently XEmacs usually attempts to autodetect packages based on
the location of the `xemacs' binary and the installation prefix, we
hope that it would be unnecessary.

The context is that Ben Wing has proposed a patch which provides
--package-prefix as a simple interface to --package-path.  That is,
--package-prefix=$dir is equivalent to specifying 

--package-path=$early::$dir/site-packages:$dir/xemacs-packages:$dir/mule-packages

with the exact specification of $early under discussion (Ben specified
$early as ~/.xemacs, but that is probably incorrect.)

Here are some considerations that have been advanced in discussion so
far.

  o Are multiple prefixes allowed?
  o If not, does that mean we are deprecating multiple hierarchies?
  o If not, we still need --package-path, don't we?
  o Is it a good idea to enforce ~/.xemacs as the early-packages
    prefix?
  o If --package-prefix forces ~/.xemacs as the early-packages
    prefix, we still need --package-path, don't we?
  o How should --package-prefix interact with EMACSPACKAGEPATH?
  o Should there be an EMACSPACKAGEPREFIX environment variable?

  o What do --package-path and --package-prefix imply about where
    package-admin should install packages?
  o How should --package-prefix and --package-path interact with
    --with-prefix=no?
  o Does handling --package-prefix in the general case require changes
    to the package-path-finding code?

We also should consider whether simplification of package location
specification interacts with longer term plans for the packages:

  o Getting rid of the special treatment of mule-packages.
  o Inverting the package hierarchy (ie, true run-in-place package
    sources).



-- 
Graduate School of Systems and Information Engineering   University of Tsukuba
http://turnbull.sk.tsukuba.ac.jp/        Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
        Economics of Information Communication and Computation Systems
          Experimental Economics, Microeconomic Theory, Game Theory