-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
core: use request.el to check elpa archive availability
Add request.el to core/libs Refactor package.el initialization in configuration-layer.el Cosmetic improvements to loading messages Remove redefinition of package-refresh-packages
- Loading branch information
Showing
7 changed files
with
1,471 additions
and
110 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,70 @@ | ||
;;; request-deferred.el --- Wrap request.el by deferred | ||
|
||
;; Copyright (C) 2012 Takafumi Arakaki | ||
|
||
;; Author: Takafumi Arakaki <aka.tkf at gmail.com> | ||
;; Package-Requires: ((deferred "0.3.1") (request "0.2.0")) | ||
;; Version: 0.2.0 | ||
|
||
;; This file is NOT part of GNU Emacs. | ||
|
||
;; request-deferred.el is free software: you can redistribute it and/or modify | ||
;; it under the terms of the GNU General Public License as published by | ||
;; the Free Software Foundation, either version 3 of the License, or | ||
;; (at your option) any later version. | ||
|
||
;; request-deferred.el is distributed in the hope that it will be useful, | ||
;; but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
;; GNU General Public License for more details. | ||
|
||
;; You should have received a copy of the GNU General Public License | ||
;; along with request-deferred.el. | ||
;; If not, see <http://www.gnu.org/licenses/>. | ||
|
||
;;; Commentary: | ||
|
||
;; | ||
|
||
;;; Code: | ||
|
||
(require 'request) | ||
(require 'deferred) | ||
|
||
(defun request-deferred (url &rest args) | ||
"Send a request and return deferred object associated with it. | ||
Following deferred callback takes a response object regardless of | ||
the response result. To make sure no error occurs during the | ||
request, check `request-response-error-thrown'. | ||
Arguments are the same as `request', but COMPLETE callback cannot | ||
be used as it is used for starting deferred callback chain. | ||
Example:: | ||
(require 'request-deferred) | ||
(deferred:$ | ||
(request-deferred \"http://httpbin.org/get\" :parser 'json-read) | ||
(deferred:nextc it | ||
(lambda (response) | ||
(message \"Got: %S\" (request-response-data response))))) | ||
" | ||
|
||
(let* ((d (deferred:new #'identity)) | ||
(callback-post (apply-partially | ||
(lambda (d &rest args) | ||
(deferred:callback-post | ||
d (plist-get args :response))) | ||
d))) | ||
;; As `deferred:errorback-post' requires an error object to be | ||
;; posted, use `deferred:callback-post' for success and error | ||
;; cases. | ||
(setq args (plist-put args :complete callback-post)) | ||
(apply #'request url args) | ||
d)) | ||
|
||
(provide 'request-deferred) | ||
|
||
;;; request-deferred.el ends here |
Oops, something went wrong.
d822241
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without having looked at the diff—sorry 😊—I presume that this implies vendoring
request.el
to support the bootstrap phase, doesn't it?d822241
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, request.el is now in
core/lib
.Maybe we should give it a new name so that packages can still depend on (and succesfully load) request.el from upstream?
d822241
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheBB I don't know, I guess that depends on when and where
core/lib
is put intoload-path
, and whether it's registered as a package for package.el. If it's put onload-path
after package paths (i.e. added before callingpackage-initialize
—I know, it's confusing) and not registered in package.el, it'd be safe I think because it's only loaded ifrequest.el
wasn't installed as a package, i.e. when spacemacs bootstraps.OTOH, I think one could implement this with
url-retrieve
andwith-timeout
, but that's probably not really convenient.d822241
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But really, I don't know, I was just curious on how you've solved this problem, because Cask supposedly has the same problem—none reported it hitherto, but we're not doing anything with timeouts when we run
package-refresh-contents
during the bootstrapping phase.d822241
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But if another package calls
(require 'request)
, Emacs checks whether request is in the list of features, e.g. whether(featurep 'request)
is true. If it is, nothing will happen, I believe, regardless of packages or load path.Packages that depend on request will be able to download it and install it, but this version will take precedence since it's loaded before.
d822241
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheBB I'm not sure. If the package load path comes before
core/lib
, and a package hasrequest.el
in its requirements, i.e. would causerequest.el
to be installed as a dependency, then thatrequest.el
would go first inload-path
.Sure, that doesn't change anything for the current session, but if Emacs is restarted
(require 'request)
will hit the installedrequest.el
, because it comes before the vendored one fromcore/lib
.IOW, the vendored library would only ever be used in the very first Spacemacs session, when Spacemacs has to bootstrap. After that,
request.el
is installed as a package and subsequent sessions would use the package.I'm mostly guessing, though, and don't know whether Spacemacs really behaves that way.
d822241
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we can ditch the artificial inclusion on request.el in core/lib I'm all for it, I had an egg and chicken issue so I included it but it is far from ideal, relying on pure url.el would be ideal.
Actually I wonder why I went straight to request.el for this :-)
d822241
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More info on this:
d822241
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lunaryorn @TheBB I removed the dependency on request.el in commit 741bd03