bug#14941: 24.3.50; package.el should lighten up wrt version specification

bug#14941: 24.3.50; package.el should lighten up wrt version specification

[Drew Adams]

File headers are for human readers too, not just for tools.

1. `package-buffer-info' should treat "Version: " as "Version: 0"

`package-buffer-info' has this code, which is the wrong thing to do:

(let* ((requires-str (lm-header "package-requires"))
        ;; Prefer Package-Version; if defined, the package author
        ;; probably wants us to use it.  Otherwise try Version.
       (pkg-version
         (or (package-strip-rcs-id (lm-header "package-version"))
             (package-strip-rcs-id (lm-header "version")))))
  (unless pkg-version
    (error "Package lacks a \"Version\" or \"Package-Version\" header"))

A user should be able to use "Version: ", i.e., specify explicitly that
there is no version, and have that be treated the same as "Version: 0".
Version is not just for package.el.  It is a field that conveys
versioning info to human readers.  An empty Version field can be used to
indicate explicitly that the file is not versioned.

2. More generally, package.el should treat the lack of a version spec
the same way it currently treats version 0.  If Package-Requires
specifies "0" for some file, it means that ANY version of that file is
OK, and that should apply also to a lack of a version spec for that
file.

Package-Requires should be able to specify that there is a dependency on
a particular file, by name, but any copy of that file will do - any
version or any copy that has no version specified.  It is important to
be able to express this kind of dependency - any foo.el and not any
specific version of foo.el - and it in no way limits package.el to allow
this.

3. In keeping with #2, package.el should allow Package-Requires, like
Version, to lack a version number for a given file, and have that be
interpreted as version "0" for that file, meaning that any version of
the file will do.  IOW, allow this:

;; Package-Requires ((foo.el))

to mean the same as this:

;; Package-Requires ((foo.el "0"))


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-07-14 on ODIEONE
Bzr revision: 113423 lekktu@gmail.com-20130715004922-i67tg2ois14h3fpm
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS='-O0 -g3' CPPFLAGS='-Ic:/Devel/emacs/include'
 LDFLAGS='-Lc:/Devel/emacs/lib''

bug#14941: [Patch] Lighten up wrt version specification

[Tom Willemse]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

Hey,

I said I would look at this bug and so I did. Sorry it took me so long
to undertake any action on it.

The attached merge directive/patch should take care of point #1, the
first half of #2 and point #3. Please let me know if you agree, I'll
happily fix any use cases you had in mind that still don't work.

In regard to the second half of #2, about requiring specific files,
instead of packages. How would you have package.el handle these when
downloading packages from ELPA or installing a package or file? Would
you have them skipped or would requiring a specific file prevent it from
being used in the same way? Or would the use have to make sure that file
is in their `load-path' before installing the package? What is the
use-case you have in mind?

Please let me know what you think, any comments, criticisms and
considerations would be greatly appreciated.


[-- Attachment #2: Lighten up, patch --]
[-- Type: text/plain, Size: 3722 bytes --]

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: tom@ryuslash.org-20140220224957-aaup04ijncvyccgn
# target_branch: bzr://bzr.sv.gnu.org/emacs/trunk/
# testament_sha1: aec87ee7f2e339fadc41ed24fff80aebd511513f
# timestamp: 2014-02-20 23:52:58 +0100
# base_revision_id: michael.albinus@gmx.de-20140220182640-\
#   jsvhe3qwzk6yylu5
# 
# Begin patch
=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2014-02-20 14:24:13 +0000
+++ lisp/ChangeLog	2014-02-20 22:49:57 +0000
@@ -1,3 +1,11 @@
+2014-02-20  Tom Willemse  <tom@ryuslash.org>
+
+	* emacs-lisp/package.el (package--prepare-dependencies): Default
+	to version "0" when no version has been specified, but a list is
+	still used.
+	(package-buffer-info): If no version header has been specified or
+	no value has been specified, default to version "0".
+
 2014-02-20  Michael Albinus  <michael.albinus@gmx.de>
 
 	* net/tramp.el (ls-lisp-use-insert-directory-program): Declare.

=== modified file 'lisp/emacs-lisp/package.el'
--- lisp/emacs-lisp/package.el	2014-02-12 01:20:34 +0000
+++ lisp/emacs-lisp/package.el	2014-02-20 22:49:57 +0000
@@ -1128,6 +1128,8 @@
                  ((symbolp dep) `(,dep "0"))
                  ((stringp dep)
                   (error "Invalid requirement specifier: %S" dep))
+                 ((and (listp dep) (null (cdr dep)))
+                  (list (car dep) "0"))
                  (t dep)))
               deps))))
 
@@ -1155,11 +1157,9 @@
 	   ;; probably wants us to use it.  Otherwise try Version.
 	   (pkg-version
 	    (or (package-strip-rcs-id (lm-header "package-version"))
-		(package-strip-rcs-id (lm-header "version"))))
+		(package-strip-rcs-id (lm-header "version"))
+                "0"))
            (homepage (lm-homepage)))
-      (unless pkg-version
-	(error
-	 "Package lacks a \"Version\" or \"Package-Version\" header"))
       (package-desc-from-define
        file-name pkg-version desc
        (if requires-str

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWW3peRYAAl7fgAA3UHf/914k
BIC////wUAV48dSlU9gBpdgoOYACYAAmAAAAAAlECGTE0Kn6p6ajyh6ag2oAGQHqBKCnqaappp7U
CND0gAANAeiNANNSg9T1AAAYENGQGQNAwEkhAE0YCA0TZBCRo00yeoMiiqFMLX6tfFGet7RS+ZeX
MsMtj500XRXtIQqJJ3iUaOFsMmpKlMwJCec6Fqk5fNukrc3zTNRVQWfulk6mUMi4md8mQaRXUzvi
pzg15gMonIGXUvKTNX7UWkBjbOfUxIH2IiSCICYIzccxDzyXEPvuhjMNSwOYwWjHyCDCHd/Ll5ZH
nRtAz4lqe7IvI+m4OB7/4Ym/cUG8dIDARmgDyVjOrbyyOKgfHsHyK9suVDXsVZN0DqFyGkxDgZzF
JwJ7QEYqHc2gsFCBANqZe73JBbWSIT0EbBqAnfYRkR37jg9uASRpsPm10utQYs1MoHHcS928LkkC
g59ryItFv8WUT6KhK8neImgQGbGhcm1ak+cwmXfCSOOewJd0mMxWQVOF9Fko7XSUQZoqmiYVLu70
KgFCAQSZNgI5QH664tAyxSlNomaob6n7vjK1yQ3Mwe5rFCgtedmmUtstHujbRJvXRGIBCAMSSm5g
ON5tMTUPhKAwWBSnLUYjuGEDPUgoIqaSFBUEjCx2EQKNpn78yEk5J/Q9gYXvF7TMdOc/GNMzGBxc
pHZfknKQhhiDykvU9xWBUOqHGGEo58IqJIOL5GAc88eMBZY8KDU1U8jTHlV+T6uLRgFgWVYF+igO
UyytMjaJLoCsweNVaRbaKwqoMRzQK7iqyMQLYRsS6HWaUOFFHUDrzdwqIDgiBdoFCT7kpIMM3Zh2
oalkTe0AiKni7lxsgbzl1zAzw4eqRgFYTVBoIs9UaB6/kxMYvnMp9lSB4u4jWrgiA2mh426GWUp5
PC7egqCvTkVhto5ko8NAJ7dnUzK4Uv79SHCuK4Cch7xAc+iPG55QKiJhF9/R4RoIo0HYv01kURGE
QQdeXEaOLxjE0DeSDLWVBaZpp/l77ArMjacysGMBhQLNWUOy7+Y8xx4KpSNnSzjImDeXCuuFYTEw
duLwzr9nSWC+DAkONvJGIPq6MfZjA5nXPebyMVRuOS8pgemGRWNlZfGgk4LImRGh39k21M3uexq5
A63YJ3eJdTwDg57FQaEbxf0ZnA5pio7rBBSxf6JEjIYf8B4AVfKIKoih+lJCcE6MJ9CNROJvmVB+
B1QWwtRLknCwAgKB+BjXUfujXOfPgG62LAStnL0dwL4h3AClY3HZMIxRHAYZIkQ5wOEcAlE49bsD
OYt3G8yUY6IwI/JLjzDe5ghANEeaxNmBllDpIsEqCSg4DjKqiuKm4VwfwDQg5Eb1BYV/eycN4Til
YJrXpcuhyBgcUBb+Lz8kgjjMJcpDWRI/ZIoX6PWHh1iyKGMgONFyPqdGaUyiGCNSigU6p8CS3EP4
UhLl4cOZD0ek0EFBPlrUiQ+XO+CZ0kBEA9RGBOKBsVYTWQtIEVMgjW5ajegoQ4oCyYRNEGwVLk3p
ZQiFLs11OhZXqGHM9sMawjvbBjxBOzezTLTHjsLi5FI6ySFEUWbBfcDqlaxxH9KwUzwqPAiMcTfq
ESeBskW9HnhxApP5+kxxKgiLA6/C6hqRUYrlzKwMFAR9E8p7cFuVH/i7kinChINvS8iw

bug#14941: [Patch] Lighten up wrt version specification

[Stefan Monnier]

> @@ -1128,6 +1128,8 @@
>                   ((symbolp dep) `(,dep "0"))
>                   ((stringp dep)
>                    (error "Invalid requirement specifier: %S" dep))
> +                 ((and (listp dep) (null (cdr dep)))
> +                  (list (car dep) "0"))
>                   (t dep)))
>                deps))))

I installed this hunk, but not the other.  If a "Version:" header is
missing, it should stay as an error, because package.el relies heavily
on version numbers.  And if the user can write "Version:" she can just
as easily write "Version:0".


        Stefan

bug#14941: [Patch] Lighten up wrt version specification

[Drew Adams]

> I installed this hunk, but not the other.

IOW, you did not fix bug #14941.  Neither the "this hunk" nor "the
other" you refer to are part of the bug 14941 thread; they are part of
#15108.  Please change bug #14941 to "wont-fix", which correctly reflects
its new status.

> If a "Version:" header is missing, it should stay as an error, because
> package.el relies heavily on version numbers.

There is no such "because" - illogical.  That package.el relies heavily
on version numbers is irrelevant.  It need not rely on the presence of
a `Version:' specification to nevertheless rely on a version number.

It need simply consider lack of an explicit `Version:' spec as
specifying version 0.  It is reasonable to have a default behavior,
and that is the right default value.

As for `Version: ' vs `Version: 0': As the bug #14941 report says, an
empty version field can indicate - to human readers - that the file is
not versioned.  For package.el it means only that any version will do
when the file is required.  But to humans it can indicate more: that the
file is not versioned.  This is a minor point, but there is no reason
for package.el to require the explicit "0".

It's a program.  It can assume "0" for an empty field here, just as it
can assume `Version: 0' for no version spec.

bug#14941: [Patch] Lighten up wrt version specification

[Stefan Monnier]

> There is no such "because" - illogical.  That package.el relies heavily
> on version numbers is irrelevant.

Of course it's relevant.  It means that unversioned packages are (very) rare.


        Stefan

bug#14941: [Patch] Lighten up wrt version specification

[Drew Adams]

> > There is no such "because" - illogical.  That package.el relies heavily
> > on version numbers is irrelevant.
>
> Of course it's relevant.  It means that unversioned packages are (very)
> rare.

Once again you've distorted things by cutting out the context and the
argument.  An unfortunate MO.

You claimed that BECAUSE package.el relies heavily on version numbers it
NEEDS explicit `Version:' specs as well.  That is the invalid argument I
flagged.  As you are well aware, I'm sure.

   It need not rely on the presence of a `Version:' specification to
   nevertheless rely on a version number.  It need simply consider lack
   of an explicit `Version:' spec as specifying version 0.

And now you make another invalid argument:

> [That package.el relies heavily on version numbers] MEANS that
> unversioned packages are (very) rare.

It of course means no such thing.

Perhaps you are really trying to say that BECAUSE package.el requires
explicit version specs, packages without them are rare?  That would be
a valid argument, but irrelevant - see above: versioned (for package.el)
need not imply an explicit version spec.

(And as I said, that package.el needs a version (explicit or by default)
for its own use does not imply that humans might not consider a given
file otherwise unversioned.)

Finally, another invalid argument:

You now use the fact that you see few headers with spec `Version: 0',
and few with no `Version:' spec, as evidence that there would also be
few such even if package did not require a non-blank `Version:' spec.
That doesn't follow either.

Obviously, if you require every package to be painted blue then you
will see, as a result, mainly - no, only - blue packages.

Again, please classify bug #14941 as "wont-fix", since your decision
was not to fix it.

bug#14941: [Patch] Lighten up wrt version specification

[Stefan Monnier]

> Once again you've distorted things by cutting out the context and the
> argument.  An unfortunate MO.

Sorry, but it's just like TV: you have to condense your message to be
short enough hat it fits in my attention span.


        Stefan

bug#14941: [Patch] Lighten up wrt version specification

[Drew Adams]

> > Once again you've distorted things by cutting out the context and the
> > argument.  An unfortunate MO.
> 
> Sorry, but it's just like TV: you have to condense your message to be
> short enough hat it fits in my attention span.

You mean like this? (3rd attempt) -

  Again, please classify bug #14941 as "wont-fix",
  since your decision was not to fix it.