The previous patches are changing the behavior in a user visible way for
recipes. Update user documentation to reflect the change and upgrade the
minor version number to be able to track this.
This refactoring is about cleaning up the code and separating it into
smaller files (think modules). We begin to change the internal API to
always receive PACKAGE as a symbol, and the main change is how we deal with
the dependencies.
Rather than allow parallel async operations to happen, we solve the
dependencies upfront by doing a topological sort of the :depends we
recursively read in the recipe files. That allows us to then install only
one package at a time and to avoid initializing the same package twice in
case of multiple reverse depends in the selection.
That in turns allows to simplify the autoload and the main install code a
lot and goes a long way to fix the bug from issue #400 where a package is
said installed but its autoload are not yet available.
The el-get-methods are also splitted each into their own file and the new
function `el-get-register-method' allows to easily add some more privately
if necessary, and should ease contributing new ones too.
This refactoring merge also brings in some test cases.
The main reason why we can merge such a big refactoring now is that the
master's branch targets el-get contributors or elisp hackers that will
handle the breakage. The el-get-install.el installer file is targeting the
branch "3.stable" where things still work. This all new setting of the code
is intended for release 4.1, not before.
Conflicts:
el-get.el
Note that the new dependencies code ensures that we have only one package
currently installing at any time, so that we don't need timer and defered
autoloads updating anymore. That simplifies the code a lot, and I think it
fixes issue #400, will check that next.
This includes teaching methods that they now work with a symbolp PACKAGE,
some more cleaning up, and some load-path adjustments now that a part of the
code is in a subdirectory (methods).
Also include some of the tests used to convince oneself that the refactoring
didn't break any and all use cases for el-get, with some rough documentation
about how to use them.
Some bugs are blocking users in 2.stable and the code diverted enough to
warrant releasing 3.1 rather than spending time fixing 2.stable. Also, it's
been a long time without release and we have some excellent new
features (dependency support, el-get-list-packages, etc).
The el-get recipe is already refering to the 3.stable branch, that will be
created from this commit.
We were failing to find the package in the list of packages to init and so
considered them for installation again. As el-get-install will respect the
current package status, that would result in the package not being
initialized at startup.
Bug found while reading the code to prepare the 3.1 release.
That was called el-get-configs-dir, rename to stick to existing emacs
facilities such as user-init-file and user-emacs-directory. Also move the
loading code into a new function el-get-load-package-user-init-file, so that
it's possible to call it by itself, and so that it can log what happens.
Support lazy loading of config files and load all config files before :after
Fixed typo in el-get-configs-dir comment
Add a wrapping function for user init file paths
* Implement 'el-get-list-packages'
(defun el-get-list-packages ()
"Display a list of packages."
* Implement 'el-get-package-menu-sort-by-column'
Sort the package menu by the last column clicked on.
Provide a shortcut, :type emacsmirror.
(:name foo :type emacsmirror)
is equivalent to
(:name foo :type git :url "http://github.com/emacsmirror/foo.git")
except that the URL is user-configurable by customize. We default to
http, but the user can choose https or git protocols if they prefer.
Additionally, we retrofit old recipes to use this shortcut. Any
package whose name matches its emacsmirror repo name
qualifies. Certain packages, such as sunrise-x-*, are no longer
entire git repositories, and so don't qualify. bookmark+
does not qualify because its name in emacsmirror is spelled
bookmark-plus. Similarly, color-theme-zenburn is just called zenburn,
so cannot be simplified this way.
We also add a few new recipes for emacsmirror packages, since it's so easy.
The implementation is based on the code for `describe-function' from GNU/Emacs 24.
Added support for :website and :description package properties. Which are used by el-get-describe and el-get-describe-1.
This should bring a much easier to understand semantics, near of that of
apt-get and friends: by default, any installed package is automatically
initialized at next startup without special care. If you don't need local
recipes, you don't need to edit and maintain any `el-get-sources'.
It's still possible to manually prepare a list of packages to install, so
that you can share your setup between multiple installations. To do that,
give the package list (names or symbols) to the (el-get) call in your setup.
This way you can also maintain specific lists depending on system or network
or whatever is useful for you. That's the advanced setup, documented.
