On Tue, 30 Jul 2019, Artur Tarassow wrote: > Hi all, > > Since gretl supports the idea of package dependencies now, I think > it's useful to add an accessor to a package's version for checking > that the required version is actually installed on the system. > > In python one has those magic methods of which one is > PACKAGE.__version__. Do we have such an accessor available in gretl? > Given that it exists in the spec-file it should be possible to grab > it, or not? If you know where your package file is located, you could use our xmlget() function, as in <hansl> pkgdata = readfile(&quot;(a)dotdir/functions/latextab.gfn&quot;) eval xmlget(pkgdata, "/gretl-functions/gretl-function-package/version") </hansl>

That said, we could have a "version" qualifier to the "pkg" command, and possibly store the output under some $-accessor ($result, maybe?).

On Tue, 30 Jul 2019, Artur Tarassow wrote: > Am 30.07.19 um 09:36 schrieb Riccardo (Jack) Lucchetti: >> On Tue, 30 Jul 2019, Artur Tarassow wrote: >> >>> Hi all, >>> >>> Since gretl supports the idea of package dependencies now, I think >>> it's useful to add an accessor to a package's version for checking >>> that the required version is actually installed on the system. >>> >>> In python one has those magic methods of which one is >>> PACKAGE.__version__. Do we have such an accessor available in gretl? >>> Given that it exists in the spec-file it should be possible to grab >>> it, or not? >> >> If you know where your package file is located, you could use our >> xmlget() function, as in >> >> <hansl> >> pkgdata = readfile(&quot;(a)dotdir/functions/latextab.gfn&quot;) >> eval xmlget(pkgdata, "/gretl-functions/gretl-function-package/version") >> </hansl> > > I was thinking about the same, but this won't work if the package is > located somewhere else. true >> That said, we could have a "version" qualifier to the "pkg" command, >> and possibly store the output under some $-accessor ($result, maybe?). > > You mean something like(?): > <hansl> > pkg version armax > eval $pkg_version > </hansl> > > "$result" sounds much more general, returning the details of the > author etc. Maybe one could name it "$pkg_version" as "$version" is > already used for accessing the installed gretl version. or perhaps <hansl> pkg info armax bundle b = $result </hansl>

On Tue, 30 Jul 2019, Artur Tarassow wrote: >> <hansl> >> pkg info armax >> bundle b = $result >> </hansl> >> > > Looks good to me ;-) Let's see what others have to say on this. Or we could simply use a function with an optional argument for non-standard locations:

On Tue, 30 Jul 2019, Artur Tarassow wrote: > This is an extended version which also works for packages in a > separate folder: [...] Nice! > Maybe we should put this function into extra.gfn...

On Wed, 31 Jul 2019, Sven Schreiber wrote: > Am 30.07.2019 um 12:12 schrieb Riccardo (Jack) Lucchetti: >> On Tue, 30 Jul 2019, Artur Tarassow wrote: >> >> >>> This is an extended version which also works for packages in a >>> separate folder: >> >> [...] >> >> Nice! >> >>> Maybe we should put this function into extra.gfn... > > Hi, I'm not against adding such a function, per se. But I think the > given example is not ready yet.

I agree. If accessing this sort of package information is something that's important for scripting, then it should be implemented by either a built-in function or an extension of the "pkg" command -- since gretl itself is pretty good at finding packages in reasonably standard locations. (With, perhaps, a "find it somewhere weird" option.)

On Thu, 1 Aug 2019, Artur Tarassow wrote: > >> I also think that implementing it natively either through a >>