I realize ASDF does some degree of version identification and control on
defsystems but this does not extend to the actual packages.
If the user has their init file load "PACKAGEX" v1.0 into their
environment and your software needs "PACKAGEX" v2.0 to run, how does one
normally handle this situation?
Trying to leverage the :documentation* string seems unwise since I read
some implementations don't include the doc strings in images and/or
(compile-file ...) fasls?
Is it best to just stuff a version number in the package name?
Are there better ways to approach this problem?
Thanks,
JCR
J.C. Roberts <···············@abac.com> writes:
> I realize ASDF does some degree of version identification and control on
> defsystems but this does not extend to the actual packages.
>
> If the user has their init file load "PACKAGEX" v1.0 into their
> environment and your software needs "PACKAGEX" v2.0 to run, how does one
> normally handle this situation?
>
> Trying to leverage the :documentation* string seems unwise since I read
> some implementations don't include the doc strings in images and/or
> (compile-file ...) fasls?
>
> Is it best to just stuff a version number in the package name?
IMO, yes.
> Are there better ways to approach this problem?
Basically, appending a version number to the package name (and
prepending a reversed domain name) is the best. Then you can add
support for relative package names: check Franz's Hierarchical Packages:
http://www.franz.com/support/tech_corner/hierpackuser.lhtml
The main problem is that the nicknames of a package is a global
property, for the package, giving one namespace for all package
names and nicknames. We'd need distinct namespaces. We could
introduce package aliases, which would be like package nicknames, but
they'd depend on the current package; the reader would have to check
the aliases of the current package before finding a global package
nickname or name.
(in-package :app-one)
(ALIAS-PACKAGE :com.informatimago.common-lisp.graph/3.2.1 :graph)
...
(add-edge (make-instance 'graph ...) node1 node2)
(in-package :app-two)
(ALIAS-PACKAGE :net.common-lisp.examplelib.graph/4.3.2 :graph)
...
(add-edge (make-edge node1 node2) :to (make-graph :directed t))
...
(defpackage :app-three
(:use :cl)
(:ALIASES (:com.informatimago.common-lisp.list :list)
(:com.hp.zebu :lalr)))
(in-package :app-three)
...
(lalr:parse (list:flatten tree))
...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
J.C. Roberts <···············@abac.com> writes:
> I realize ASDF does some degree of version identification and control on
> defsystems but this does not extend to the actual packages.
>
> If the user has their init file load "PACKAGEX" v1.0 into their
> environment and your software needs "PACKAGEX" v2.0 to run, how does one
> normally handle this situation?
>
> Trying to leverage the :documentation* string seems unwise since I read
> some implementations don't include the doc strings in images and/or
> (compile-file ...) fasls?
>
> Is it best to just stuff a version number in the package name?
>
> Are there better ways to approach this problem?
Well, there isn't any really great answer to this, although several
methods have been used:
1) Encode the version number into *features*. This seems to be fairly
popular with lisp implementations. Under the general assumption that
most implementations remain backward compatible, the version numbers
will often accumulate. In other words, :packageX-1.0 and :packageX-2.0
are frequently both present.
This doesn't help with comparisons for greater than, although Allegro
does have an extension to their read-time conditionalization that can
test for versions greater than a specified version.
2) Put the version number either as a float or a string into a special
variable or constant in the system in question. Then you can do
whatever comparisons you want. Floats will work for two-part version
numbers, but not the common 3-part variety.
I would avoid putting it into package names unless you expect to need to
run multiple versions in the same image and need to keep them straight.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> J.C. Roberts <···············@abac.com> writes:
>
> > I realize ASDF does some degree of version identification and control on
> > defsystems but this does not extend to the actual packages.
> >
> > If the user has their init file load "PACKAGEX" v1.0 into their
> > environment and your software needs "PACKAGEX" v2.0 to run, how does one
> > normally handle this situation?
> >
> > Trying to leverage the :documentation* string seems unwise since I read
> > some implementations don't include the doc strings in images and/or
> > (compile-file ...) fasls?
> >
> > Is it best to just stuff a version number in the package name?
> >
> > Are there better ways to approach this problem?
>
> Well, there isn't any really great answer to this, although several
> methods have been used:
>
> 1) Encode the version number into *features*. This seems to be fairly
> popular with lisp implementations. Under the general assumption that
> most implementations remain backward compatible, the version numbers
> will often accumulate. In other words, :packageX-1.0 and :packageX-2.0
> are frequently both present.
>
> This doesn't help with comparisons for greater than, although Allegro
> does have an extension to their read-time conditionalization that can
> test for versions greater than a specified version.
>
>
> 2) Put the version number either as a float or a string into a special
> variable or constant in the system in question. Then you can do
> whatever comparisons you want. Floats will work for two-part version
> numbers, but not the common 3-part variety.
A variant of this is to put the version somewhere on the plist of the
keyword you put in *features*. Perhaps people find that ugly, but I
think there's some neatness in that.
',mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
I wish you had gotten a good answer to this. For what I want to do, it
would be important to recreate computations based on the original state
of the system (i.e. exploratory statistical computations for data
analysis for drug development), with potentially overlapping
dependencies. i.e. criticalPackage1v1 depends on criticalPackage2v4
but I might have criticalPackage1v23 which depends on a changed
API/functionality found in criticalPackagev32. So for new work, I
prefer to use the latter combination, but for old work, it is important
to use the first combination. But one could imagine intermediate
stages of development which rely on both (i.e. criticalPackage1v4 still
relies on criticalPackage2v4).
Now, I could "hardcode" the load-locations for the packages, but that's
an increase in effort, and subject to system admin whims and system
rebuilding. What I'd like is to be able to stick all these packages
in the same place for ease of loading, and add hints as to the range of
the "other package" which work with it, and have a partial-ordering
(not a full ordering, thanks to SCM branching) of versions with ranges.
(so basically, I'd like to augment the current package loaders/builders
with a partial-ordered versioning scheme, i.e. a directed acyclic graph
of versions, and mappings between trees for valid combinations of
versions -- this to be maintained by the developer. I just want the
subsequent "loading" ((and unloading) based on version to work.
Best,
-tony