Actually, ELPA will only set load-path way later after reading init.el,
which breaks everything that depends on an ELPA package and is loaded just
after el-get, at init time.
Signed-off-by: Julien Danjou <julien@danjou.info>
That cleans up the code and allow not to depend on the :reload property, and
cater with some edge cases like features currently loaded but no longer
present in the updated package.
Conflicts:
el-get.el
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
