Function to retrieve package version

Function to retrieve package version

[Paul W. Rankin]

wrt. 
http://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00022.html

I would like an easy function that retrieves the version of the 
current package, e.g.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;;; my-great-package.el --- A great package

;; Copyright (c) 1952-2019  Free Software Foundation, Inc.

;; Author: Mr. Big Pants <mister@bigpants.com>
;; Version: 2.7.0
;; Package-Requires: ((emacs "24.5"))

(defvar my-great-package-version
  (package-get-version))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    my-great-package-version
    -> "2.7.0"

-- 
https://www.paulwrankin.com

Re: Function to retrieve package version

[Michael Albinus]

"Paul W. Rankin" <hello@paulwrankin.com> writes:

> wrt. http://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00022.html
>
> I would like an easy function that retrieves the version of the
> current package, e.g.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ;;; my-great-package.el --- A great package
>
> ;; Copyright (c) 1952-2019  Free Software Foundation, Inc.
>
> ;; Author: Mr. Big Pants <mister@bigpants.com>
> ;; Version: 2.7.0
> ;; Package-Requires: ((emacs "24.5"))
>
> (defvar my-great-package-version
>  (package-get-version))
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>    my-great-package-version
>    -> "2.7.0"

(or (lm-header "package-version")
    (lm-header "version"))

Best regards, Michael.

Re: Function to retrieve package version

[Paul W. Rankin]

On Tue, May 21 2019, Michael Albinus wrote:
>>    my-great-package-version
>>    -> "2.7.0"
>
> (or (lm-header "package-version")
>     (lm-header "version"))

Thanks Michael, this is the best!

The lisp-mnt library should be added to the Elisp manual :)

Re: Function to retrieve package version

[Michael Albinus]

"Paul W. Rankin" <hello@paulwrankin.com> writes:

>> (or (lm-header "package-version")
>>     (lm-header "version"))
>
> Thanks Michael, this is the best!
>
> The lisp-mnt library should be added to the Elisp manual :)

Yes, I was first looking there, and couldn't find it.

Do you want to contribute a patch? Or at least a bug report? (I'm
completely short in time; otherwise I would do it myself)

Best regards, Michael.

Re: Function to retrieve package version

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > The lisp-mnt library should be added to the Elisp manual :)

  > Yes, I was first looking there, and couldn't find it.

Please don't do that.  The manual is very long already.  That makes
printing expensive.  Before we add a new topic, we need to consider
whether the benefit is worth the increase in cost.

You write it and put it in an @ifnottex conditional.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Function to retrieve package version

[Stefan Monnier]

> (defvar my-great-package-version
>  (package-get-version))

C-h o package-get-version RET says:

    package-get-version is an autoloaded compiled Lisp function in ‘package.el’.
    
    (package-get-version)
    
      This function does not change global state, including the match data.
    
    Return the version number of the package in which this is used.
    Assumes it is used from an Elisp file placed inside the top-level directory
    of an installed ELPA package.
    The return value is a string (or nil in case we can’t find it).


-- Stefan

Re: Function to retrieve package version

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (defvar my-great-package-version
>>  (package-get-version))
>
> C-h o package-get-version RET says:
>
>     package-get-version is an autoloaded compiled Lisp function in ‘package.el’.
>     
>     (package-get-version)
>     
>       This function does not change global state, including the match data.
>     
>     Return the version number of the package in which this is used.
>     Assumes it is used from an Elisp file placed inside the top-level directory
>     of an installed ELPA package.
>     The return value is a string (or nil in case we can’t find it).

Aren't there a set of functions that start from a package name string,
rather than the current file? I thought there were functions that would
first retrieve a struct from your installed files, then extract a
name/version from that?

Re: Function to retrieve package version

[Paul W. Rankin]

On Wed, May 22 2019, Richard Stallman wrote:
> Please don't do that.  The manual is very long already.  That 
> makes
> printing expensive.  Before we add a new topic, we need to 
> consider
> whether the benefit is worth the increase in cost.

Can you elaborate on what you mean here Richard? Do you mean 
people printing the Elisp manual themselves, or does the FSF print 
copies of the Elisp manual gratis?

If the former, surely the benefit of Emacs Lisp package 
maintainers knowing about the built-in "utility functions for 
Emacs Lisp maintainers" outweighs the miniscule additional cost of 
a couple of paragraphs that might add a single page to the printed 
output, which at the very most (barring some sort of OCD 
condition) will be printed once per major release?

And if I'm going to the trouble/expense of printing the entire 
Elisp manual, I damn sure want it to be as complete as possible, 
rather than later discover it's missing key topics and so will 
require a reprint. The idea that I'm being miserly about my stock 
of printer paper in this scenario is a little unrealistic...

Re: Function to retrieve package version

[Eli Zaretskii]

On May 22, 2019 5:02:20 AM GMT+03:00, "Paul W. Rankin" <hello@paulwrankin.com> wrote:
> 
> On Wed, May 22 2019, Richard Stallman wrote:
> > Please don't do that.  The manual is very long already.  That 
> > makes
> > printing expensive.  Before we add a new topic, we need to 
> > consider
> > whether the benefit is worth the increase in cost.
> 
> Can you elaborate on what you mean here Richard? Do you mean 
> people printing the Elisp manual themselves, or does the FSF print 
> copies of the Elisp manual gratis?
> 
> If the former, surely the benefit of Emacs Lisp package 
> maintainers knowing about the built-in "utility functions for 
> Emacs Lisp maintainers" outweighs the miniscule additional cost of 
> a couple of paragraphs that might add a single page to the printed 
> output, which at the very most (barring some sort of OCD 
> condition) will be printed once per major release?
> 
> And if I'm going to the trouble/expense of printing the entire 
> Elisp manual, I damn sure want it to be as complete as possible, 
> rather than later discover it's missing key topics and so will 
> require a reprint. The idea that I'm being miserly about my stock 
> of printer paper in this scenario is a little unrealistic...

Richard means the manual whjch the FSF prints and sells.  If it's too large, it will be more expensive.

But there's a way to have that cake and eat it, too: we can have certain portions of the manual conditioned by @ifnottex.  We already do that for some less important topics.  So there's no need to argue about this particular case.

Re: Function to retrieve package version

[Paul W. Rankin]

On Wed, May 22 2019, Eli Zaretskii wrote:
> Richard means the manual whjch the FSF prints and sells.  If 
> it's too large, it will be more expensive.
>
> But there's a way to have that cake and eat it, too: we can have 
> certain portions of the manual conditioned by @ifnottex.  We 
> already do that for some less important topics.  So there's no 
> need to argue about this particular case.

Makes sense. But getting immediate pushback just means I won't be 
contributing the topic.

Re: Function to retrieve package version

[Michael Albinus]

"Paul W. Rankin" <hello@paulwrankin.com> writes:

> On Wed, May 22 2019, Eli Zaretskii wrote:
>> Richard means the manual whjch the FSF prints and sells.  If it's
>> too large, it will be more expensive.
>>
>> But there's a way to have that cake and eat it, too: we can have
>> certain portions of the manual conditioned by @ifnottex.  We already
>> do that for some less important topics.  So there's no need to argue
>> about this particular case.
>
> Makes sense. But getting immediate pushback just means I won't be
> contributing the topic.

In the given case, I believe it is not mandatory to document the whole
lisp-mnt package. It would suffice to document `lm-header' in the node
"(elisp) Library Headers".

Best regards, Michael.

Re: Function to retrieve package version

[Eli Zaretskii]

> From: "Paul W. Rankin" <hello@paulwrankin.com>
> Cc: emacs-devel@gnu.org, rms@gnu.org, Michael Albinus <michael.albinus@gmx.de>
> Date: Wed, 22 May 2019 12:49:09 +1000
> 
> getting immediate pushback just means I won't be contributing the
> topic.

Not sure what you mean by that, Richard just asked not to add stuff
automatically without considering whether it's justified:

  Before we add a new topic, we need to consider whether the benefit
  is worth the increase in cost.

I see no negative pushback here, but that's me.

Re: Function to retrieve package version

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Can you elaborate on what you mean here Richard?

No time today.  I am overloaded.  But maybe someone else
can explain this to you.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)