req-package doesn't install single packages via el-get

Question

req-package doesn't install single packages via el-get

aspiers opened this issue 9 years ago · 27 comments

There seem to be two issues here:

There is no concrete example in the documentation of how to use :loader. Should it be (req-package foo :loader el-get), or (req-package foo :loader 'el-get), or maybe even (req-package foo :loader (el-get))?
I've tried all of these and none of them work.

I looked into the elisp:

 (defun req-package-providers-prepare (package &optional loader)
  "Prepare PACKAGE - install if it is present using LOADER if specified."
  (condition-case e
      (if (functionp loader)
          (funcall loader package)

If loader is el-get and package is a single symbol (e.g. 'xrdb-mode), then this will effectively attempt (el-get 'xrdb-mode). But the first parameter to el-get gets treated as the SYNC parameter, so el-get treats its PACKAGES parameter as nil, and nothing gets installed.

Answer 1 · 2016-02-01T07:20:15.000Z

Hello. Sorry for the delay. Just came back from vacation. I will investigate it soon

Answer 2 · 2016-02-23T16:24:19.000Z

Thanks, looking forward to your thoughts!

Answer 3 · 2016-02-23T20:22:47.000Z

I made a quick fix, but it's not compatible with current version. You should use keywords to specify loaders from now on.

Answer 4 · 2016-02-23T20:33:30.000Z

Thanks a lot! But please can you also document how to use it? I have no clue right now...

Answer 5 · 2016-02-23T20:57:57.000Z

Ah, just came up with understanding that this is not gonna work. The reason is keywords are used for arguments parsing..

Answer 6 · 2016-02-23T20:59:04.000Z

Need to introduce something like a list of known keywords, I think

Answer 7 · 2016-02-23T20:59:24.000Z

And of course, I'll document it

Answer 8 · 2016-02-23T20:59:55.000Z

Great, thanks :)

Answer 9 · 2016-02-24T06:01:41.000Z

@aspiers please, check it out, I hope it works for you now

Answer 10 · 2016-02-24T13:02:18.000Z

I'm trying aspiers/emacs@15fb700 but it doesn't install xrdb-mode at all, so the autoload fails.

Answer 11 · 2016-02-24T13:03:13.000Z

And there's nothing relevant shown by M-x req-package--log-open-log.

Answer 12 · 2016-02-24T14:29:09.000Z

Let me try the same in hour

On Wed, Feb 24, 2016, 8:03 PM Adam Spiers notifications@github.com wrote:

And there's nothing relevant shown by M-x req-package--log-open-log.

—
Reply to this email directly or view it on GitHub
#29 (comment).

Answer 13 · 2016-02-24T15:14:31.000Z

Hm. It works for me. Are you sure you're on the latest req-package?

Answer 14 · 2016-02-24T16:48:06.000Z

Yes I upgraded, reloaded all elisp files, and then even restarted emacs ...

On 24 February 2016 at 15:14, Edward Knyshov notifications@github.com
wrote:

Hm. It works for me. Are you sure you're on the latest req-package?

—
Reply to this email directly or view it on GitHub
#29 (comment).

Answer 15 · 2016-02-24T17:54:10.000Z

May I ask you your emacs version?

On Wed, Feb 24, 2016 at 11:48 PM Adam Spiers notifications@github.com
wrote:

Yes I upgraded, reloaded all elisp files, and then even restarted emacs ...

On 24 February 2016 at 15:14, Edward Knyshov notifications@github.com
wrote:

Hm. It works for me. Are you sure you're on the latest req-package?

—
Reply to this email directly or view it on GitHub
<#29 (comment)
.

—
Reply to this email directly or view it on GitHub
#29 (comment).

Answer 16 · 2016-02-24T18:24:42.000Z

And also req-package snapshot version could help a lot

On Thu, Feb 25, 2016 at 12:53 AM Edward Knyshov edvorg@gmail.com wrote:

May I ask you your emacs version?

On Wed, Feb 24, 2016 at 11:48 PM Adam Spiers notifications@github.com
wrote:

Yes I upgraded, reloaded all elisp files, and then even restarted emacs
...

On 24 February 2016 at 15:14, Edward Knyshov notifications@github.com
wrote:

Hm. It works for me. Are you sure you're on the latest req-package?

—
Reply to this email directly or view it on GitHub
<#29 (comment)
.

—
Reply to this email directly or view it on GitHub
#29 (comment).

Answer 17 · 2016-02-24T21:27:23.000Z

GNU Emacs 24.5.1 (x86_64-suse-linux-gnu, GTK+ Version 3.14.3) of 2015-11-13 on cumulus2
req-package-20160223.2200 from MELPA

Answer 18 · 2016-02-25T09:44:19.000Z

@aspiers your req-package version is old, take new one req-package-20160224.331
Look at the badge on readme page

Answer 19 · 2016-02-25T09:45:11.000Z

package-refresh-contents

Answer 20 · 2016-02-26T17:10:52.000Z

@edvorg Before testing, I checked to make sure that req-package-20160223.2200 had the fixes in, and it did AFAICS. But I can try a newer one too.

Answer 21 · 2016-02-27T08:56:27.000Z

Also, as req-package is a macro, you should recompile (clean up and compile again) all your configuration files using it.

Answer 22 · 2016-02-27T16:42:26.000Z

My config files aren't compiled, so a restart of emacs already covers this case. It's still definitely not working, even with req-package-20160225.155:

https://github.com/aspiers/emacs/blob/master/.emacs.d/init.d/as-config-langs.el#L11

Answer 23 · 2016-02-27T16:43:19.000Z

req-package--log-open-log says:

16:39:31 [INFO ] installing package xrdb-mode

but el-get clearly shows that xrdb-mode is not installed, and it's not on the filesystem anywhere.

Answer 24 · 2016-04-18T15:50:15.000Z

I am still seeing this with req-package-20160227.1005 ! Please can you reopen this issue? It is not fixed. I have looked closer and identified the following issues:

req-package-providers-el-get-present is cached via defconst, so if el-get is loaded after req-package, req-package mistakenly thinks el-get is not available.
req-package-providers-prepare calls (funcall installer package) and then ignores the result. So if the installer fails, req-package silently fails.
Even if the funcall succeeds, the (require package nil t) code which comes immediately after it is part of the ELSE clause of the if, so the package only gets required if installer was nil. Huh?

Answer 25 · 2016-04-18T16:01:27.000Z

As discussed by private email, I'll try to fix these. However would be really helpful if you could explain whether that ELSE clause is there intentionally, and if so, what the reason is - it looks backwards to me :-)

Answer 26 · 2016-04-18T16:04:20.000Z

Another problem: the code doesn't ensure that the el-get package gets added to load-path. This only happens the times when req-package actually invoked el-get to install the package. On other times, it sees it's already installed, and doesn't do what's required to add it to the load-path, so the require would fail even if it wasn't in the ELSE clause.

Answer 27 · 2016-04-18T16:36:29.000Z

@aspiers

req-package-providers-el-get-present is cached via defconst, so if el-get is loaded after req-package, req-package mistakenly thinks el-get is not available.

agree, this requires a better check for el-get presence, maybe just try to require it

req-package-providers-prepare calls (funcall installer package) and then ignores the result. So if the installer fails, req-package silently fails.

as you can see this code is wrapped into condition case and expecting to get an error if something fails in installer.

Even if the funcall succeeds, the (require package nil t) code which comes immediately after it is part of the ELSE clause of the if, so the package only gets required if installer was nil. Huh?

afair this thing tries to cover the case when we just have some *.el file on load-path. not a good solution, because this code loads this el file. We better should solve it with new providers system somehow.