Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Wondering whether anyone had time to give me feedback on this. It
> provides a mechanism to have ELPA packages bundle with core Emacs.

Sorry for taking so long.  I just took a look at it, and it looks fairly
simple and clean.  But I think the main question is *if* we really want
to use this to build the official tarballs.  I think we should, but IIRC
Eli wasn't quite as enthusiastic about it.

>  - Doesn't use package.el (I think this is an anti-feature, but tried
>    that before and no one liked it)

That doesn't ring a bell.  Could you refresh our memory why no one
liked it?

> --- /dev/null
> +++ b/notes.org
> @@ -0,0 +1,84 @@
> +
> +
> +* Working on
> +
> +Have package checkout working for external
> +Next get it working for non external so we can template

Don't know what you mean by "can template"

> +* To Fix
> +Think we are running git fetch --all on every package.

Don't know what you're referring to here either.

> +1) Scripting?
> +Guess we have to use sh

Of course, we could also use Elisp ;-)

> +2) How to get specific directory of a repository
> +
> +
> +
> +git archive --remote=phillord@git.savannah.gnu.org:/srv/git/emacs/elpa.git master packages/hydra | tar xv --strip-components=1
> +
> +Currently, this requires a member login -- it doesn't work with http
> +or the current git server.
> +
> +Would also be possible to configure this from local.

I'm not familiar with `git archive` but does this require network access?

> +3) How to work out when a directory is out of date wrt to the make
> +   file

Don't know what you mean here.

> +4) Heuristics for working out which files to copy to right place
> +
> +*-test.el
> +*-tests.el
> +/test/*.el
> +
> +to test
> +
> +All other *el to lisp
> +
> +Nothing else

Rather than heuristics, I'd go for a *rules* (which needs to be obeyed
before the package can be bundled).

But I'm not sure we should install those packages with a different
layout than for a "normal" ELPA install.
What's the advantage of using a different layout?

> +6) How to enable ELPA packages to customize the process
> +Add the option to run an core-deploy.sh file placed into the root of a
> +package.

Don't know what you mean here.

> +8) Support other repos
> +Org-mode effectively does this already

Don't know what you mean here.

> --- /dev/null
> +++ b/elpa/bin/extract-package.sh
> @@ -0,0 +1,55 @@
> +#!/bin/bash
> +
> +function grab_external {
> +    rm -rf packages/$PACKAGE*
> +    mkdir --parents $PACKAGE_LOC
> +    cwd=`pwd`
> +    cd $GIT_LOC
> +    git archive $SHA \
> +        | tar xv -C $cwd/$PACKAGE_LOC
> +    cd $cwd
> +    cp --no-clobber bin/package-makefile.mk $PACKAGE_LOC

Rather than `cd $cwd`, I generally prefer to use (...) to save&restore
the current directory:

    cwd=`pwd`
    (cd $GIT_LOC
     git archive $SHA \
         | tar xv -C $cwd/$PACKAGE_LOC)
    cp --no-clobber bin/package-makefile.mk $PACKAGE_LOC

If we keep the layout unchanged, we could use `git worktree add`, which
has the advantage that when running Emacs in-place, jumping to the
source in `C-h f` and friends gives you access to the Git metainfo.


        Stefan