Listing packages in machine-readable form w/ versioning info?
Howdy -- As best I can tell, there are currently two ways to list installed packages: - The REPO LIST command, which returns complete output, but in a format clearly intended for human consumption. - The repo:list() function, which is more programatically accessible but returns only namespaces (no version numbers)... simply repeating a single namespace twice if two versions of that package are installed. A mechanism to access the installed package list which includes versioning and directory info (the latter to allow uninstallation of a specific version using repo:delete) would be useful.
Hi Charles, if you delete packages, it is sufficient to specify the namespace, which is why I'm inclined to disallow the installation of a package that has already been installed with a different version - or automatically replace/update it. What do you think? Beside that, we may still extend the output of the repo:list() function to sth. similar to the following example: <package uri="http://www.functx.com" version="1.0"/> ... As a sidenote: some time ago, we have started some internal discussions on alternatives to the EXPath Packaging spec, which are easier to build and maintain. If anyone thinks that sounds interesting: your thoughts are welcome. Christian __________________________ On Wed, Feb 22, 2012 at 8:07 PM, Charles Duffy <charles@dyfis.net> wrote:
Howdy --
As best I can tell, there are currently two ways to list installed packages:
- The REPO LIST command, which returns complete output, but in a format clearly intended for human consumption. - The repo:list() function, which is more programatically accessible but returns only namespaces (no version numbers)... simply repeating a single namespace twice if two versions of that package are installed.
A mechanism to access the installed package list which includes versioning and directory info (the latter to allow uninstallation of a specific version using repo:delete) would be useful.
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Christian Grün wrote: Hi,
if you delete packages, it is sufficient to specify the namespace, which is why I'm inclined to disallow the installation of a package that has already been installed with a different version - or automatically replace/update it. What do you think?
In xrepo, the command-line program to manage an on-disk repository, the remove operation takes an optional version number as parameter. If it is not there and there is only one version installed, it is removed. If the version number is there, only that version of the package is removed, if any. Note also that the package is identified by a name, which is a URI, but is not (necessarily) a namespace URI.
Beside that, we may still extend the output of the repo:list() function to sth. similar to the following example:
<package uri="http://www.functx.com" version="1.0"/> ...
What "xrepo list" outputs is something like: http://example.org/lib/my-pkg 1.0.0, in my-pkg-1.0.0 1.0.1, in my-pkg-1.0.1 http://example.com/lib/something-else 2.3, in something-else-2.3 Of course, this is text-oriented because it is called by humans from the command line, but the idea remains the same (and the "in" is the name of the sub-directory within the repository directory where the package is installed, which might have no sense in a repository not on disk).
alternatives to the EXPath Packaging spec, which are easier to build and maintain.
The versioning issues can seem sometimes a bit of extra work, but in my humble opinion this is a key factor for building a robust, built- to-last packaging system. As per easiness of building packages, you can have a look at XProject at http://expath.org/modules/xproject/, which provides a tool to automatically build a package based on few meta-information about the project itself and annotations within the components (or directly the target namespace within the XQuery library modules). In particular, there is a plugin for oXygen that contains everything ready-to-be-installed in oXygen and providing all features via simple buttons: http://expath.org/modules/xproject/oxygen. Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/
An option to automatically replace would be better than nothing... but my immediate use case is determining whether a DELETE/INSTALL cycle is necessary by comparing version numbers, which I'm presently implementing by parsing REPO LIST output. In the case where the user running my tools doesn't have admin access on the database, I'd like to at least tell them that installation of a newer version is necessary, even if they don't have the privileges to perform it themselves. Regarding the packaging format -- I find the EXPath spec workable (there's much to be said for multiple vendor implementations); it was a matter of minutes to put together a makefile and some helpers to automate both package creation and installation (though those helpers are a bit hackier than I'd like right now, having to parse human-targeted output to determine the current version installed to compare it to the one just built). On Sun, Feb 26, 2012 at 9:46 AM, Christian Grün <christian.gruen@gmail.com>wrote:
Hi Charles,
if you delete packages, it is sufficient to specify the namespace, which is why I'm inclined to disallow the installation of a package that has already been installed with a different version - or automatically replace/update it. What do you think?
Beside that, we may still extend the output of the repo:list() function to sth. similar to the following example:
<package uri="http://www.functx.com" version="1.0"/> ...
As a sidenote: some time ago, we have started some internal discussions on alternatives to the EXPath Packaging spec, which are easier to build and maintain. If anyone thinks that sounds interesting: your thoughts are welcome.
Christian __________________________
On Wed, Feb 22, 2012 at 8:07 PM, Charles Duffy <charles@dyfis.net> wrote:
Howdy --
As best I can tell, there are currently two ways to list installed packages:
- The REPO LIST command, which returns complete output, but in a format clearly intended for human consumption. - The repo:list() function, which is more programatically accessible but returns only namespaces (no version numbers)... simply repeating a single namespace twice if two versions of that package are installed.
A mechanism to access the installed package list which includes versioning and directory info (the latter to allow uninstallation of a specific version using repo:delete) would be useful.
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Charles, we've decided to update the repo:list() function: it now returns element nodes including the package versions. Hope this helps, Christian ___________________________ On Sun, Feb 26, 2012 at 6:49 PM, Charles Duffy <charles@dyfis.net> wrote:
An option to automatically replace would be better than nothing... but my immediate use case is determining whether a DELETE/INSTALL cycle is necessary by comparing version numbers, which I'm presently implementing by parsing REPO LIST output. In the case where the user running my tools doesn't have admin access on the database, I'd like to at least tell them that installation of a newer version is necessary, even if they don't have the privileges to perform it themselves.
Regarding the packaging format -- I find the EXPath spec workable (there's much to be said for multiple vendor implementations); it was a matter of minutes to put together a makefile and some helpers to automate both package creation and installation (though those helpers are a bit hackier than I'd like right now, having to parse human-targeted output to determine the current version installed to compare it to the one just built).
On Sun, Feb 26, 2012 at 9:46 AM, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Charles,
if you delete packages, it is sufficient to specify the namespace, which is why I'm inclined to disallow the installation of a package that has already been installed with a different version - or automatically replace/update it. What do you think?
Beside that, we may still extend the output of the repo:list() function to sth. similar to the following example:
<package uri="http://www.functx.com" version="1.0"/> ...
As a sidenote: some time ago, we have started some internal discussions on alternatives to the EXPath Packaging spec, which are easier to build and maintain. If anyone thinks that sounds interesting: your thoughts are welcome.
Christian __________________________
On Wed, Feb 22, 2012 at 8:07 PM, Charles Duffy <charles@dyfis.net> wrote:
Howdy --
As best I can tell, there are currently two ways to list installed packages:
- The REPO LIST command, which returns complete output, but in a format clearly intended for human consumption. - The repo:list() function, which is more programatically accessible but returns only namespaces (no version numbers)... simply repeating a single namespace twice if two versions of that package are installed.
A mechanism to access the installed package list which includes versioning and directory info (the latter to allow uninstallation of a specific version using repo:delete) would be useful.
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
we've decided to update the repo:list() function: it now returns element nodes including the package versions.
..and yet another update: repo:list() can now be run by all users, no matter what permissions they have (before, it was in fact limited to admins).
participants (3)
-
Charles Duffy -
Christian Grün -
Florent Georges