Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Epl find available packages broken on snapshot #18

Open
rejeep opened this issue Feb 15, 2014 · 4 comments
Open

Epl find available packages broken on snapshot #18

rejeep opened this issue Feb 15, 2014 · 4 comments
Labels

Comments

@rejeep
Copy link
Member

rejeep commented Feb 15, 2014

@lunaryorn,

It seems that epl-find-available-packages behaves differently on 24.3.1 and 24.3.50.1.

In 24.3.50.1, if you have installed a package with the most recent version available, then it will not be added to package-archive-contents when you call (package-refresh-contents). The function epl-find-available-packages checks if the package is in package-archive-contents, which it might not be.

Here's some code to reproduce the issue:

(let ((flycheck (assq 'flycheck package-alist)))
  (let (package-alist package-archive-contents)
    (push flycheck package-alist)
    (package-refresh-contents)
    (print (format "in package-alist: %s"
                   (not (not (assq 'flycheck package-alist)))))
    (print (format "in package-archive-contents: %s"
                   (not (not (assq 'flycheck package-archive-contents)))))))

The package is however available in package-alist. What we could do is that we extend epl-find-available-packages so that it first checks package-archive-contents and then package-alist.

What do you think?

@rejeep rejeep added the bug label Feb 15, 2014
@swsnr
Copy link
Contributor

swsnr commented Feb 15, 2014

@rejeep Er, no, I'd rather not do this.

epl-find-available-packages returns packages which are available for installation. That's not the same as a package currently being installed.

Namely, I can install Flycheck from MELPA, and afterwards remove the MELPA archive again. Now, Flycheck is still installed as in epl-package-installed-p, and returned by epl-installed-packages and epl-find-installed-package, but it is not available for installation anymore. Namely, if I remove Flycheck now with epl-package-delete, I cannot re-install it anymore. Also, Emacs cannot update this package anymore.

As such, epl-find-available-package should not return it anymore. In fact, changing this function to also consider installed packages would break epl-upgrade, and probably others as well.

“Installed packages”, and “packages available for installation” are simply two different things, and each has its own functions (epl-available-packages and epl-installed-packages respectively).

@swsnr
Copy link
Contributor

swsnr commented Feb 15, 2014

@rejeep Ah, I probably misunderstood you. It seems, as if snapshot doesn't add an available package to package-archive-contents, if it is already installed. That's unfortunate, but still, we can't change epl-find-available-package, because as above, available and installed packages are technically different.

Actually, I don't think that this is our fault. While I can understand the motivation to keep installed packages out of package-archive-contents, it is a semantically questionable decision, because it makes package-archive-contents reflect something else than the actual contents of the package archives (namely, archive minus installed packages), and leaves us without any chance to get the real contents of the archives.

As such, I think this is actually more of an issue in Emacs than in EPL. I'd go so far as to say that it is a bug. Did you report it to the Emacs developers?

@rejeep
Copy link
Member Author

rejeep commented Feb 15, 2014

As such, I think this is actually more of an issue in Emacs than in EPL

Yes, I agree. I will report it and see what they have to say about it. Thanks for your input!

@dsedivec
Copy link

dsedivec commented Apr 1, 2017

PSA: From reading other issues, I think rejeep reported this to Emacs in #16762, which sounds like it was fixed and closed in April 2014, released with Emacs 24.4. rejeep's code in his first comment is returning t for me in both cases, which I believe to be the desired output. I'm guessing this issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants