Recognizing obsolete external package versions

Recognizing obsolete external package versions

[Richard Stallman]

Would someone please implement that feature?

Re: Recognizing obsolete external package versions

[Glenn Morris]

Richard Stallman wrote:

> Would someone please implement that feature?

Will this do?


(defconst bad-packages-list
  '((semantic (string-equal semantic-version "2.0pre3")
              (format "Semantic 2.0pre3 won't run in Emacs %s.
It causes excessive CPU load.  Update to a newer version."
                      emacs-major-version))
    ;; Install run-time check for older versions of CUA-mode, which
    ;; does not work with GNU Emacs version 22.1 and newer.
    ;;
    ;; Except for version 1.2, all of the 1.x and 2.x version of cua-mode
    ;; provided the `CUA-mode' feature.  Since this is no longer true,
    ;; we can warn the user if the `CUA-mode' feature is ever provided.
    (CUA-mode t (format "\n\nCUA-mode is now part of the standard \
GNU Emacs distribution, so you may
now enable CUA via the Options menu or by customizing option `cua-mode'.\n
You have loaded an older version of CUA-mode which does
not work correctly with this version of GNU Emacs.\n\n%s"
                        (if user-init-file
                            (format "To correct this, remove the loading and \
customization of the
old version from the %s file.\n\n" user-init-file)
                          ""))))
  "List of packages known to cause problems in this version of Emacs.
Each element has the form (PACKAGE TESTFUNC MSGFUNC).  Upon
loading PACKAGE, evaluate TESTFUNC, and if it returns non-nil
signal an error with message given by evaluating MSGFUNC.")

(defun bad-package-check (package)
  "Run a check using an element from `bad-packages-list'.
Use the element matching the symbol PACKAGE.  This function is
added to `after-load-alist'."
  (let ((list (assoc package bad-packages-list)))
    (and list
         (condition-case nil
             (eval (nth 1 list))
           (error nil))
         (error (eval (nth 2 list))))))

(mapc (lambda (elem)
        (eval-after-load (car elem) `(bad-package-check ',(car elem))))
      bad-packages-list)

Re: Recognizing obsolete external package versions

[Lennart Borgman (gmail)]

Glenn Morris wrote:
> Richard Stallman wrote:
> 
>> Would someone please implement that feature?
> 
> Will this do?
> 
> 
> (defconst bad-packages-list
>   '((semantic (string-equal semantic-version "2.0pre3")


What if even older versions of semantics are used?

Re: Recognizing obsolete external package versions

[Glenn Morris]

"Lennart Borgman (gmail)" wrote:

> What if even older versions of semantics are used?

Yes, what if they are? If you have evidence that they cause a problem,
then obviously the semantic-version test can be generalized.

Re: Recognizing obsolete external package versions

[Glenn Morris]

Glenn Morris wrote:

> "Lennart Borgman (gmail)" wrote:
>
>> What if even older versions of semantics are used?
>
> Yes, what if they are? If you have evidence that they cause a problem,
> then obviously the semantic-version test can be generalized.

Trivially, I might add, given the existence of the `version<' function.

Does anyone actually know which are the problematic semantic versions?
The NEWS entry is not specific.

Re: Recognizing obsolete external package versions

[Richard Stallman]

That code seems basically right
except that I would rather it avoid calling eval.
It should give the name of a variable, and the values that are bad.

I think it would be better to check at the beginning of loading the file
rather than at the end.  That is possible by searching for "(defvar VARIABLE",
evaluating the sexp that comes next, and looking at its value.

That would require detecting the file by its name rather than by
a feature it provides.

Re: Recognizing obsolete external package versions

[Stefan Monnier]

> I think it would be better to check at the beginning of loading the file
> rather than at the end.

Why would that matter?  The user will have to fetch and install a new
package, maybe tweak her .emacs, ... most likely she'll have plenty of time
and reasons to restart her Emacs process at some point in-between anyway.

> That is possible by searching for "(defvar VARIABLE",
> evaluating the sexp that comes next, and looking at its value.

That sounds like a lot of work for very little benefit: currently files are
loaded by doing an `fopen' and then reading and parsing directly from there,
so it's never put into a buffer where a search could take place.


        Stefan

Re: Recognizing obsolete external package versions

[Richard Stallman]

    > I think it would be better to check at the beginning of loading the file
    > rather than at the end.

    Why would that matter?

So that it won't actually load the version that causes trouble.
With semantic, that causes hangs, right?

    > That is possible by searching for "(defvar VARIABLE",
    > evaluating the sexp that comes next, and looking at its value.

    That sounds like a lot of work for very little benefit: currently files are
    loaded by doing an `fopen' and then reading and parsing directly from there,
    so it's never put into a buffer where a search could take place.

It won't be a big loss to read the whole file and search it before
loading it, if we only do it for a few recognized file names.

Re: Recognizing obsolete external package versions

[Stefan Monnier]

>     Why would that matter?

> So that it won't actually load the version that causes trouble.
> With semantic, that causes hangs, right?

I don't think the hang is caused just by loading the file.
And to avoid such risks, we could just call unload-feature.

But in any case, I'd first try the approach proposed by Glenn, and if/when
we bump into a case where "after-load" is too late, we may then consider
a more complex solution.  My guess is that this will never be necessary.


        Stefan

Re: Recognizing obsolete external package versions

[Richard Stallman]

    But in any case, I'd first try the approach proposed by Glenn, and if/when
    we bump into a case where "after-load" is too late, we may then consider
    a more complex solution.  My guess is that this will never be necessary.

Ok, let's try it.  Please avoid calling eval, as I said before.

To make sure that the user actually sees the warning, please use
display-warning to display it.

Re: Recognizing obsolete external package versions

[Glenn Morris]

Richard Stallman wrote:

> Ok, let's try it.  Please avoid calling eval, as I said before.

It seems a silly restriction to me, but I can't be bothered to argue.
So I checked in a version that uses half as many evals, is twice as
ugly, and half as useful.

> To make sure that the user actually sees the warning, please use
> display-warning to display it.

ok.

Re: Recognizing obsolete external package versions

[Glenn Morris]

Richard Stallman wrote:

> That code seems basically right except that I would rather it avoid
> calling eval. It should give the name of a variable, and the values
> that are bad.

I don't see the problem with eval, given that we write the code that
gets evalled, and this feature would not be for external use. If you
are worried about malicious code in the filed being loaded, well, it's
already been loaded at this point, so if it wanted to do anything
nasty it could have done so directly without needing to go through
this mechanism. No different to any other external package.

> I think it would be better to check at the beginning of loading the
> file rather than at the end. That is possible by searching for
> "(defvar VARIABLE", evaluating the sexp that comes next, and looking
> at its value.

Oof. This seems like overkill, as has been said.

> That would require detecting the file by its name rather than by
> a feature it provides.

eval-after-load can work with file names as well; so the mechanism I
proposed can already work with either features or filenames. But it is
_after_ load, of course.

Re: Recognizing obsolete external package versions

[Richard Stallman]

    I don't see the problem with eval, given that we write the code that
    gets evalled, and this feature would not be for external use. If you
    are worried about malicious code in the filed being loaded, well, it's
    already been loaded at this point, so if it wanted to do anything
    nasty it could have done so directly without needing to go through
    this mechanism. No different to any other external package.

It is cleaner to make the code more specific.
For instance, issuing a warning in a standard way.

Re: Recognizing obsolete external package versions

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> That code seems basically right
> except that I would rather it avoid calling eval.
> It should give the name of a variable, and the values that are bad.
>
IIRC, we discurage inclusion of version strings in packages.

And even if there is a version string, there is no guarangee that the
version string is stored in a variable.


> I think it would be better to check at the beginning of loading the file
> rather than at the end.  That is possible by searching for "(defvar VARIABLE",
> evaluating the sexp that comes next, and looking at its value.

For the CUA-mode check, there is no such version variable ... instead, it
is simply the presence of the `CUA-mode' feature which triggers the warning.

I could also imagine that for some packages, checking for an old
version need to e.g. check for the (non-)presense of some function or
variable.

>
> That would require detecting the file by its name rather than by
> a feature it provides.

What method would you use to trigger the checking _before_ the load
(even before reading the file)?

AFAICS, we only have eval-after-load to play with here.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Recognizing obsolete external package versions

[Richard Stallman]

    > That code seems basically right
    > except that I would rather it avoid calling eval.
    > It should give the name of a variable, and the values that are bad.
    >
    IIRC, we discurage inclusion of version strings in packages.

We discurage inclusion of version variables
in packages that are part of Emacs.  However, the use of this
feature is for packages that are not part of Emacs.
They normally do have version numbers.

    For the CUA-mode check, there is no such version variable ... instead, it
    is simply the presence of the `CUA-mode' feature which triggers the warning.

That is a valid point.

    What method would you use to trigger the checking _before_ the load
    (even before reading the file)?

It would need new code at the C level in Fload, I think.

Recognizing obsolete external package versions

[Richard Stallman]

Would someone please implement that feature?