Re: [nongnu] elpa/cider ff1de2bd22: [#3113] Hardcode cider-version as a workaround

Re: [nongnu] elpa/cider ff1de2bd22: [#3113] Hardcode cider-version as a workaround

[Stefan Monnier]

>     [#3113] Hardcode cider-version as a workaround
>     
>     I can't figure out why the auto-extraction of the version doesn't work.
[...]
> -(defconst cider-version
> -  (lm-version (or load-file-name buffer-file-name))
> +(defconst cider-version "1.2.0"
>    "The current version of CIDER.")

I suspect the problem may be that `load-file-name` will point at
`cider.elc` where `lm-version` won't find what you need.

You can try and use `package-get-version` (new in Emacs-27) which tries
to get this working.


        Stefan

Re: [nongnu] elpa/cider ff1de2bd22: [#3113] Hardcode cider-version as a workaround

[Bozhidar Batsov]

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

I'm already using `package-get-version` as well, but in case they install from MELPA there's a divergence in the version that I wanted to account for, as MELPA replaces the "real" package version (e.g. 1.2) with a build timestamp. So I end up displaying to the users something like "Version 1.2.0-snapshot (package: 20211219...)" in those cases. Makes it easier for me to debug issues related to snapshot builds. Anyways, thanks a lot for the help!    

On Wed, Dec 29, 2021, at 9:32 AM, Stefan Monnier wrote:
> >     [#3113] Hardcode cider-version as a workaround
> >     
> >     I can't figure out why the auto-extraction of the version doesn't work.
> [...]
> > -(defconst cider-version
> > -  (lm-version (or load-file-name buffer-file-name))
> > +(defconst cider-version "1.2.0"
> >    "The current version of CIDER.")
> 
> I suspect the problem may be that `load-file-name` will point at
> `cider.elc` where `lm-version` won't find what you need.
> 
> You can try and use `package-get-version` (new in Emacs-27) which tries
> to get this working.
> 
> 
>         Stefan
> 
> 
> 

[-- Attachment #2: Type: text/html, Size: 1724 bytes --]

Re: [nongnu] elpa/cider ff1de2bd22: [#3113] Hardcode cider-version as a workaround

[Stefan Monnier]

> I'm already using `package-get-version` as well, but in case they install
> from MELPA there's a divergence in the version that I wanted to account for,
> as MELPA replaces the "real" package version (e.g. 1.2) with a build
> timestamp. So I end up displaying to the users something like "Version
> 1.2.0-snapshot (package: 20211219...)" in those cases. Makes it easier for
> me to debug issues related to snapshot builds. Anyways, thanks a lot for
> the help!

Right if you want to circumvent MELPA's version numbers, then you can't
just use `package-get-version`.  But you can probably steal ideas from
the code of `package-get-version` (maybe the cutest of them is to mark the
function as `pure` so it's computed during compilation) and
`macroexp-file-name` (tho this last one benefited from accompanying
changes in various "core" parts (like bytecomp.el) to make the info
available in a more convenient and robust way).


        Stefan