Hi!
Approximately after the release of ASDF 2 I've got interested in creating yet another system distribution management system on top of ASDF, and that made me investigate ASDF internals. Through that investigation, I've understood 2 things: * ASDF has support for much more, than is well known and in ordinary use by most Common Lisp programmers :) * still it's support for versioning (which is essential to distribution management) is lacking due to: - possibility to specify only exact version - somewhere in the depths of code version checking is lost (for example, there's no condition signaled, if in the process of system definitions traversal we load ASD file with different version for some system, that was already loaded, which actually causes errors in some situations, i.e. its a bug) - the syntax is not very friendly
So, during last month I was developing ASDF in the direction of more robust version support. I've started with 2.000, but fortunately there's no intersection between my work and recent developments up to version 2.106 (except for new DEFGENERIC*, which is trivial).
Attached is the proposed patch to ASDF, that, in my view, solves the aforementioned versioning problems. It does the following: * Unifies internal version representation format in the form of a list of integers: (for example, ASDF 2.106 will have an internal version of '(2 106 0), while ASDF 2.005 — '(2 5 0)). At the same time, the users are given quite a lot of freedom in specifying versions, for example they can do that as before in string form (like "1.2.3"), so it's backwards compatible. This new format is more programming-friendly and several utility functions are added: PROPER-VERSION (to transform to it), V> (version-greater-or-equal), MAJOR-VERSION and MINOR-VERSION,— while VERSION-SATISFIES is much improved in the manner, that is explained below. Also a method for SLOT-UNBOUND is added to VERSION slot on a SYSTEM class, to return version '(0 0 0), which is considered (on par with NIL) to be a wildcard version spec, so to say. * Adds VERSION-P (version-predicate) parameter to different ASDF functions, that need to deal with versions. This specifies in which way to match versions with VERSION-SATISFIES and currently has the following variants: :EXACT (nil also translates to :EXACT), :ABOVE, :MAJOR+, :MINOR+, and also a second version spec, which means that version should be in the interval from the given version to version-p itself. This is the change, that I had had in mind, when I started looking at ASDF * Adds a continuable error of type SYSTEM-VERSION-CONFLICT, when we try to read ASD file with a different version of some system, that is already in memory * Adds new format of version specification in :DEPENDS-ON clause of DEFSYSTEM. Besided (:version <system> <version>), which is retained and extended with version-p, i.e. (:version <system> <version> <version-p>) — example: (:version :hunchentoot "1.2.3" :above) ,— there's now also a simpler (<system> <version> <version-p>) — example: (:hunchentoot "1.2.3" :above)
A final note about versioning: I needed to use pre-reading of ASD files in order to know their versions without arising version conflicts. This works, except for the fact, that READ-EVAL is turned off in the process, so such version specifiers as: * :version #.*hunchentoot-version* * :version #.(with-open-file (vers (merge-pathnames "version.lisp-expr" *load-truename*)) (read vers)) do not produce expected results and are treated as empty versions. There will be a need to make a note about that to library developers.
Besides, an incompatible change is introduced to FIND-SYSTEM. The ERROR-P optional argument is removed, so plain NIL is unconditionally returned, when system is not found, and VERSION and VERSION-P optional arguments are added instead. I'd like to argue, that this is justified by two things: * there's no substantial use of ERROR-P argument neither in ASDF itself, nor anywhere in dependent code (at least I can tell that after a brief look at google search results) * more importantly, although there's another option to add version/version-p: add VERSION and VERSION-P as keyword arguments and leave ERROR-P also as keyword argument — I don't think, that overall the use of such argument is a proper architectural decision, because it's not an error actually, when system is not found — it's a common situation and should be dealt with in the caller appropriately to the context
My last note concerning this patch is about testing. After syncing with the development branch of ASDF, I see the addition of TEST directory. When I'd started my experiments, I had somehow missed it (or it had not been there?). Anyway, I have supplied a number of unit tests to the functions, that I have added. This is done with a very simple unit testing library of my own (a microframework so to say) MUTEST, that can be found at: http://github.com/vseloved/mutest/. The tests are specified right in the code side-by-side with functions definitions, but are protected with #+mutest guards, so effectively can be ignored. They also have the benefit of showing, how each of the functions can be called. There's also a dummy directory structure under TEST, that is used in the tests and should be reproduced in the same directory, where ASDF-VERSION.LISP is located.
I have also done functional testing of the changes with the systems, that I have got installed already (around 70 libraries), and have verified, that there are no problems. At the same time I would not claim, that there will not be any problems with some system definitions, that use obscure ASDF features (although, I have acquainted myself with ASDF to the point, that I quite well understand most of the features as well as internals now). So I ask anyone interested in this set of changes to thoroughly test them.
At the same time I'd be glad to know more about utilizing the current ASDF test-suite.
Finally, the patch can be applied by simply loading ASDF-VERSION.LISP on top of the loaded ASDF 2.106.
I hope, this work proves useful and is integrated into ASDF. Anyway I'm willing to answer any questions and/or improve the implementation, if needed.
Vsevolod Dyomkin
Dear Vsevolod,
Approximately after the release of ASDF 2 I've got interested in creating yet another system distribution management system on top of ASDF, and that made me investigate ASDF internals. Through that investigation, I've understood 2 things:
- ASDF has support for much more, than is well known and in ordinary use by
most Common Lisp programmers :)
- still it's support for versioning (which is essential to distribution
management) is lacking due to: [...]
Yes, ASDF is lacking in terms of support for versioning. And I admit I am not convinced that extending that support is a good thing. Unless you're going to reimplement and maintain something that's better than existing toolchains, then there's no point at all in the exercise: Lisp users are much better off using existing tools to manage versions than roll their own half-assed mock up. Dpkg or RPM or Nix are very well suited for managing the mix-and-match of many different versions of packages. Git or SVN are very well suited for managing the exact match of package combinations.
I'm not saying that distribution management is useless, or that you shouldn't be coding anything, but rather that there are a lot of interesting problems in the world, and a lot of things that could help the Lisp community, and that it's not obvious that yet another distribution management system is the one most worth of the *huge* cost of doing it right. — And I speak from the experience of trying to turn a simple one-sentence idea of an improvement upon ASDF into software (XCVB).
If I may suggest a simpler, cheaper and more useful strategy for helping with the version management of Lisp software, it would be to automatically produce Debian, RPM or Nix packages from ASDF specifications, and let those tools do the rest of the integration.
Attached is the proposed patch to ASDF, that, in my view, solves the aforementioned versioning problems. It does the following:
- Unifies internal version representation format in the form of a list of
integers: (for example, ASDF 2.106 will have an internal version of '(2 106 0), while ASDF 2.005 — '(2 5 0)).
Why only three integers? While you're at it, why not accept the whole range of Debian or RPM version comparisons?
A final note about versioning: I needed to use pre-reading of ASD files in order to know their versions without arising version conflicts. This works, except for the fact, that READ-EVAL is turned off in the process, so such version specifiers as:
- :version #.*hunchentoot-version*
- :version #.(with-open-file (vers (merge-pathnames "version.lisp-expr"
*load-truename*)) (read vers)) do not produce expected results and are treated as empty versions. There will be a need to make a note about that to library developers.
If we ever go this way, it might be better to extend ASDF to accept reading versions from file, either by READing an object, or by READ-LINEing it.
Besides, an incompatible change is introduced to FIND-SYSTEM. The ERROR-P optional argument is removed, so plain NIL is unconditionally returned, when system is not found, and VERSION and VERSION-P optional arguments are added instead.
This sounds very bad to me. What is the use case? How does that affect the semantics of find-system? Can there now be many instances of a system in the source-registry? Does find-system now have to grovel for *all* these instances, load the .asd files to determine the version and pick the most recent one by default? That's C R A Z Y.
Note that the current interface of find-system seems to be copied from that of find-class.
The way I see things is that whoever sets up the source-registry thereby specifies which versions of each piece of software is going to be used, at which point version management can be taken completely out of ASDF and into the hands of whoever specifies said source-registry.
If you want to check that what is configured is correct, you can check versions. And e.g. POIU, XCVB or ASDF-DEPENDENCY-GROVEL do have such consistency checks. But that's as much as you need.
I have supplied a number of unit tests to the functions, that I have added. This is done with a very simple unit testing library of my own (a microframework so to say) MUTEST, that can be found at: http://github.com/vseloved/mutest/.
I'd rather ASDF has only one test framework, if possible one with few dependencies if at all. The current one kind of sucks but works so far. I'm not against using a different one, but someone should then do the conversion of existing tests.
I have also done functional testing of the changes with the systems, that I have got installed already (around 70 libraries), and have verified, that there are no problems. At the same time I would not claim, that there will not be any problems with some system definitions, that use obscure ASDF features (although, I have acquainted myself with ASDF to the point, that I quite well understand most of the features as well as internals now). So I ask anyone interested in this set of changes to thoroughly test them.
I think that's a good strategy, and one many people have been following lately. Maybe there's a way to automate and share these things further.
Finally, the patch can be applied by simply loading ASDF-VERSION.LISP on top of the loaded ASDF 2.106.
I hope, this work proves useful and is integrated into ASDF. Anyway I'm willing to answer any questions and/or improve the implementation, if needed.
I admit this is not on top of my priority list. I'll try to review your code in detail later this week. Ideally, a new ASDF maintainer would step forward and replace me.
Thanks for your efforts,
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Most economic fallacies derive... from the tendency to assume that there is a fixed pie, that one party can gain only at the expense of another. — Milton Friedman
Dear Faré,
thanks for the detailed reply. I wanted to clarify some points below.
On Mon, Jun 28, 2010 at 4:14 PM, Faré fahree@gmail.com wrote:
Dear Vsevolod,
Approximately after the release of ASDF 2 I've got interested in creating yet another system distribution management system on top of ASDF, and
that
made me investigate ASDF internals. Through that investigation, I've understood 2 things:
- ASDF has support for much more, than is well known and in ordinary use
by
most Common Lisp programmers :)
- still it's support for versioning (which is essential to distribution
management) is lacking due to: [...]
Yes, ASDF is lacking in terms of support for versioning. And I admit I am not convinced that extending that support is a good thing. Unless you're going to reimplement and maintain something that's better than existing toolchains, then there's no point at all in the exercise: Lisp users are much better off using existing tools to manage versions than roll their own half-assed mock up. Dpkg or RPM or Nix are very well suited for managing the mix-and-match of many different versions of packages. Git or SVN are very well suited for managing the exact match of package combinations.
I'm not saying that distribution management is useless, or that you shouldn't be coding anything, but rather that there are a lot of interesting problems in the world, and a lot of things that could help the Lisp community, and that it's not obvious that yet another distribution management system is the one most worth of the *huge* cost of doing it right. — And I speak from the experience of trying to turn a simple one-sentence idea of an improvement upon ASDF into software (XCVB).
I understand that and I'm not pushing the particular issue of a distribution management tool here. I'm more in the mood of trying to build something on top of ASDF with the smallest effort. Moreover this is not directly connected to versioning issue, or let's say, proper versioning may have other application besides what I have in mind.
If I may suggest a simpler, cheaper and more useful strategy for helping with the version management of Lisp software, it would be to automatically produce Debian, RPM or Nix packages from ASDF specifications, and let those tools do the rest of the integration.
Attached is the proposed patch to ASDF, that, in my view, solves the aforementioned versioning problems. It does the following:
- Unifies internal version representation format in the form of a list of
integers: (for example, ASDF 2.106 will have an internal version of '(2
106
0), while ASDF 2.005 — '(2 5 0)).
Why only three integers? While you're at it, why not accept the whole range of Debian or RPM version comparisons?
Actually, the number of integers is not limited, it's just that this is the default practice and currently available predicates only take into account the first two. So the internal representation is a list of integers. But the user can specify versions in many different formats, like "1.2.3" or even 1.2 (float number). Moreover it's possible to build adapters for more representations by defining methods for the generic function PROPER-VERSION.
A final note about versioning: I needed to use pre-reading of ASD files
in
order to know their versions without arising version conflicts. This
works,
except for the fact, that READ-EVAL is turned off in the process, so such version specifiers as:
- :version #.*hunchentoot-version*
- :version #.(with-open-file (vers (merge-pathnames "version.lisp-expr"
*load-truename*)) (read vers)) do not produce expected results and are treated as empty versions. There will be a need to make a note about that to library developers.
To clarify my point: there are cases of libraries, that use the read-eval syntax in version definitions, most notable of which are Edi Weitz's and Cyrus Harmon's. I agree here with Robert Goldman, that this is a little contrary to the declarative nature of DEFSYSTEM form. Still it is not a problem with neither the existing, nor the proposed variants. It's just that in the FIND-SYSTEM pipeline such version declarations (or rather evaluations) won't be counted (i.e. considered equal to wildcard version). But during the evaluation of DEFSYSTEM form itself the version would be properly evaluated. So this peculiarity will effect the new behavior, but not the old, that is why I don't consider it a problem: if someone would like to use the new behavior, he is free to adapt his code, otherwise he can leave it as is and no problems would arise.
If we ever go this way, it might be better to extend ASDF to accept reading versions from file, either by READing an object, or by READ-LINEing it.
Besides, an incompatible change is introduced to FIND-SYSTEM. The
ERROR-P
optional argument is removed, so plain NIL is unconditionally returned,
when
system is not found, and VERSION and VERSION-P optional arguments are
added
instead.
This sounds very bad to me. What is the use case?
The use case is that we can now (oos 'load 'system :version "1.2.3") or write in defsystem :depends-on (system "1.2.3" :above). As all those user-facing facilities use FIND-SYSTEM as the underlying tool. Independently from adding VERSION and VERSION-P I would still argue to remove ERROR-P argument, as it adds unnecessary complexity. There's only one place in the original ASDF code (OPERATE), where it's expected and it is easily handled in the caller.
How does that affect the semantics of find-system? Can there now be many instances of a system in the source-registry?
The semantics is the following: only zero or one instance of a system with a particular name can be in memory (in *defined-systems*) — just like before. The current behavior is that if some system is loaded, there's no possibility to load the new version. The new behavior is that, if FIND-SYSTEM is forced to load the different version of the system, a continuable error is signaled, that informs the user of the situation and it's possible either to abort or continue. If the user continues, the new definition is loaded instead of the old.
Does find-system now have to grovel for *all* these instances, load the .asd files to determine the version and pick the most recent one by default? That's C R A Z Y.
Yeah, now SYSDEF-CENTRAL-REGISTRY-SEARCH et al. return a list of found ASD files instead of the first one. Then the most suitable is chosen by these criteria: * if no version is specified it will be either the one already in memory, or the first one in the list * if version is specified it will be the one in memory, if VERSION-SATISFies, or the first from a list, for which version satisfies
Note that the current interface of find-system seems to be copied from that of find-class.
Hmm, I see. I still don't support such decision, but maybe I just not understand something...
The way I see things is that whoever sets up the source-registry thereby specifies which versions of each piece of software is going to be used, at which point version management can be taken completely out of ASDF and into the hands of whoever specifies said source-registry.
Yeah, that's also a possible approach. It has it's advantages for sure.
If you want to check that what is configured is correct, you can check versions. And e.g. POIU, XCVB or ASDF-DEPENDENCY-GROVEL do have such consistency checks. But that's as much as you need.
I have supplied a number of unit tests to the functions, that I have added. This is done with a very simple unit testing library
of
my own (a microframework so to say) MUTEST, that can be found at: http://github.com/vseloved/mutest/.
I'd rather ASDF has only one test framework, if possible one with few dependencies if at all.
I agree. If there's one already chosen, I'll stick to it. as I've said, when I've started this work, I didn't find any tests, so I used my own approach. By the way MUTEST is dependency-free.
The current one kind of sucks but works so far. I'm not against using a different one, but someone should then do the conversion of existing tests.
I have also done functional testing of the changes with the systems, that
I
have got installed already (around 70 libraries), and have verified, that there are no problems. At the same time I would not claim, that there
will
not be any problems with some system definitions, that use obscure ASDF features (although, I have acquainted myself with ASDF to the point, that
I
quite well understand most of the features as well as internals now). So
I
ask anyone interested in this set of changes to thoroughly test them.
I think that's a good strategy, and one many people have been following lately. Maybe there's a way to automate and share these things further.
Finally, the patch can be applied by simply loading ASDF-VERSION.LISP on
top
of the loaded ASDF 2.106.
I hope, this work proves useful and is integrated into ASDF. Anyway I'm willing to answer any questions and/or improve the implementation, if needed.
I admit this is not on top of my priority list. I'll try to review your code in detail later this week. Ideally, a new ASDF maintainer would step forward and replace me.
Thanks for your efforts,
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Most economic fallacies derive... from the tendency to assume that there is a fixed pie, that one party can gain only at the expense of another. — Milton Friedman
Thanks, Vsevolod
: Faré
: Vsevolod Dyomkin Dear
If I may suggest a simpler, cheaper and more useful strategy for helping with the version management of Lisp software, it would be to automatically produce Debian, RPM or Nix packages from ASDF specifications, and let those tools do the rest of the integration.
I reiterate my suggestion.
Why only three integers? While you're at it, why not accept the whole range of Debian or RPM version comparisons?
Actually, the number of integers is not limited, it's just that this is the default practice and currently available predicates only take into account the first two. So the internal representation is a list of integers. But the user can specify versions in many different formats, like "1.2.3" or even 1.2 (float number). Moreover it's possible to build adapters for more representations by defining methods for the generic function PROPER-VERSION.
Once again, it would be better if you just agreed to the de facto "standard" of either Debian or RPM versioning. But once again, I think this code should NOT be part of ASDF.
To clarify my point: there are cases of libraries, that use the read-eval syntax in version definitions, most notable of which are Edi Weitz's and Cyrus Harmon's. I agree here with Robert Goldman, that this is a little contrary to the declarative nature of DEFSYSTEM form. Still it is not a problem with neither the existing, nor the proposed variants. It's just that in the FIND-SYSTEM pipeline such version declarations (or rather evaluations) won't be counted (i.e. considered equal to wildcard version). But during the evaluation of DEFSYSTEM form itself the version would be properly evaluated. So this peculiarity will effect the new behavior, but not the old, that is why I don't consider it a problem: if someone would like to use the new behavior, he is free to adapt his code, otherwise he can leave it as is and no problems would arise.
That I agree with. We should be sure to provide a simple incremental upgrade path from where we are to wherever we go.
Besides, an incompatible change is introduced to FIND-SYSTEM. The ERROR-P optional argument is removed, so plain NIL is unconditionally returned, when system is not found, and VERSION and VERSION-P optional arguments are added instead.
This sounds very bad to me. What is the use case?
The use case is that we can now (oos 'load 'system :version "1.2.3") or write in defsystem :depends-on (system "1.2.3" :above). As all those user-facing facilities use FIND-SYSTEM as the underlying tool. Independently from adding VERSION and VERSION-P I would still argue to remove ERROR-P argument, as it adds unnecessary complexity. There's only one place in the original ASDF code (OPERATE), where it's expected and it is easily handled in the caller.
This is not a use case. What is a high-level situation in which a user or developer may want to use versioning, and why should this situation be solved using FIND-SYSTEM?
How does that affect the semantics of find-system? Can there now be many instances of a system in the source-registry?
The semantics is the following: only zero or one instance of a system with a particular name can be in memory (in *defined-systems*) — just like before. The current behavior is that if some system is loaded, there's no possibility to load the new version. The new behavior is that, if FIND-SYSTEM is forced to load the different version of the system, a continuable error is signaled, that informs the user of the situation and it's possible either to abort or continue. If the user continues, the new definition is loaded instead of the old.
That sounds both complex to implement, for little value to a user.
Does find-system now have to grovel for *all* these instances, load the .asd files to determine the version and pick the most recent one by default? That's C R A Z Y.
Yeah, now SYSDEF-CENTRAL-REGISTRY-SEARCH et al. return a list of found ASD files instead of the first one. Then the most suitable is chosen by these criteria:
- if no version is specified it will be either the one already in memory, or
the first one in the list
- if version is specified it will be the one in memory, if
VERSION-SATISFies, or the first from a list, for which version satisfies
That's both expensive and backwards incompatible with current API.
I propose instead that a completely different API be used, that computes and/or checks a source-registry from some specification and a database of available system versions. i.e. layer something on top of ASDF without modifying anything about ASDF proper.
Note that the current interface of find-system seems to be copied from that of find-class.
Hmm, I see. I still don't support such decision, but maybe I just not understand something...
It's just a matter of backwards compatibility. If we're going to change how things work, I'd rather we provide a new API and declare the old one obsolete than break backwards compatibility gratuitously. Also, I'm not convinced by this :VERSION interface. Version matching is not a local problem to be solved by adding :VERSION arguments to local function calls, but a global problem to be approached by collecting (in)equations about available versions, solving these inequations, and producing a source-registry (possibly pointing to a single generated link farm) as a solution.
I'd rather ASDF has only one test framework, if possible one with few dependencies if at all.
I agree. If there's one already chosen, I'll stick to it. as I've said, when I've started this work, I didn't find any tests, so I used my own approach. By the way MUTEST is dependency-free.
I haven't looked at MUTEST yet. I'll have to do it soon. If you're willing to migrate all existing tests to it -- why not.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I once dreamt that children would be taught to not accept slogans on face value, but to see through words and look for meaning or lack thereof. However, I soon realized that by the time schools teach this piece of wisdom, it may have itself become a slogan devoid of meaning, the sense of its words having drifted or been otherwise corrupted by time and vice. You need more than dead words to have people think by themselves; you need a living tradition.
On Tue, Jun 29, 2010 at 1:00 AM, Faré fahree@gmail.com wrote:
: Faré
: Vsevolod Dyomkin Dear
If I may suggest a simpler, cheaper and more useful strategy for helping with the version management of Lisp software, it would be to automatically produce Debian, RPM or Nix packages from ASDF specifications, and let those tools do the rest of the integration.
I reiterate my suggestion.
Sorry, I've forgotten to address that. I agree, that supporting full Debian/RPM style versioning is better. I'm not currently familiar enough with that, so I will be thankful, if you point me to some good resource.
Why only three integers? While you're at it, why not accept the whole range of Debian or RPM version comparisons?
Actually, the number of integers is not limited, it's just that this is
the
default practice and currently available predicates only take into
account
the first two. So the internal representation is a list of integers.
But
the user can specify versions in many different formats, like "1.2.3" or even 1.2 (float number). Moreover it's possible to build adapters for
more
representations by defining methods for the generic function
PROPER-VERSION.
Once again, it would be better if you just agreed to the de facto "standard" of either Debian or RPM versioning. But once again, I think this code should NOT be part of ASDF.
To clarify my point: there are cases of libraries, that use the read-eval syntax in version definitions, most notable of which are Edi Weitz's and Cyrus Harmon's. I agree here with Robert Goldman, that this is a little contrary to the declarative nature of DEFSYSTEM form. Still it is not a problem with neither the existing, nor the proposed variants. It's just that in the FIND-SYSTEM pipeline such version declarations (or rather evaluations) won't be counted (i.e. considered equal to wildcard
version).
But during the evaluation of DEFSYSTEM form itself the version would be properly evaluated. So this peculiarity will effect the new behavior,
but
not the old, that is why I don't consider it a problem: if someone would like to use the new behavior, he is free to adapt his code, otherwise he
can
leave it as is and no problems would arise.
That I agree with. We should be sure to provide a simple incremental upgrade path from where we are to wherever we go.
Besides, an incompatible change is introduced to FIND-SYSTEM. The ERROR-P optional argument is removed, so plain NIL is unconditionally
returned,
when system is not found, and VERSION and VERSION-P optional arguments are added instead.
This sounds very bad to me. What is the use case?
The use case is that we can now (oos 'load 'system :version "1.2.3") or write in defsystem :depends-on (system "1.2.3" :above). As all those user-facing facilities use FIND-SYSTEM as the underlying tool. Independently from adding VERSION and VERSION-P I would still argue to remove ERROR-P argument, as it adds unnecessary complexity. There's only one place in the original ASDF code (OPERATE), where it's expected and it
is
easily handled in the caller.
This is not a use case. What is a high-level situation in which a user or developer may want to use versioning, and why should this situation be solved using FIND-SYSTEM?
Well, when the DEFSYSTEM form is traversed and dependencies are loaded the CURRENT implementation uses FIND-SYSTEM. That is why I worked with FIND-SYSTEM and not introduced some new construct to deal specifically with versioned dependencies, because it would have duplicated the same code (in case of not versioned ones — call FIND-SYSTEM, in case of versioned — FIND-VERSIONED-SYSTEM?)
How does that affect the semantics of find-system? Can there now be many instances of a system in the source-registry?
The semantics is the following: only zero or one instance of a system
with a
particular name can be in memory (in *defined-systems*) — just like
before.
The current behavior is that if some system is loaded, there's no possibility to load the new version. The new behavior is that, if FIND-SYSTEM is forced to load the different version of the system, a continuable error is signaled, that informs the user of the situation and it's possible either to abort or continue. If the user continues, the
new
definition is loaded instead of the old.
That sounds both complex to implement, for little value to a user.
It's already implemented, and the complexity you can judge for yourself. Considering the value to the user, you might be right. At least I'm not in the position to judge.
Does find-system now have to grovel for *all* these instances, load the .asd files to determine the version and pick the most recent one by default? That's C R A Z Y.
Yeah, now SYSDEF-CENTRAL-REGISTRY-SEARCH et al. return a list of found
ASD
files instead of the first one. Then the most suitable is chosen by
these
criteria:
- if no version is specified it will be either the one already in memory,
or
the first one in the list
- if version is specified it will be the one in memory, if
VERSION-SATISFies, or the first from a list, for which version satisfies
That's both expensive and backwards incompatible with current API.
Yes that's expensive, but it can be mitigated. Considering backwards incompatibility: there's no current API, I mean, those functions are not part of the APIm but auxiliary functions used solely in FIND-SYSTEM.
I propose instead that a completely different API be used, that computes and/or checks a source-registry from some specification and a database of available system versions. i.e. layer something on top of ASDF without modifying anything about ASDF proper.
Yes, that is also possible. It's just that currently ASDF has some half-baked version support and it should be either removed completely (deprecated) or improved up to usable state. I mean, that all the versions specified in current defsystem forms are hardly used by any software, that might have wanted to utilize them, and that's because of poor current implementation, I think.
Note that the current interface of find-system seems to be copied from that of find-class.
Hmm, I see. I still don't support such decision, but maybe I just not understand something...
It's just a matter of backwards compatibility. If we're going to change how things work, I'd rather we provide a new API and declare the old one obsolete than break backwards compatibility gratuitously.
Yes, I understand that. Well, actually, that is really not such a big issue, so FIND-SYSTEM can be left with the existing argument set (or, better, VERSION/VERSION-P arguments can be added to the tail of the optional list, which will be backwards compatible). It was more a suggestion towards a more clear API (and it's possible to change it, as it seems, noone is using the current one :) But I reiterate, that the issue is not critical at all.
Also, I'm not convinced by this :VERSION interface. Version matching is not a local problem to be solved by adding :VERSION arguments to local function calls, but a global problem to be approached by collecting (in)equations about available versions, solving these inequations, and producing a source-registry (possibly pointing to a single generated link farm) as a solution.
Your solution should also work. But I believe (and my limited testing has confirmed that), that a local solution is also viable, because all the inequalities in our case boil down to the separate decisions, that can be taken only by the user himself to select, which of the conflicting versions of the system should be present in his image (as there can be only one simultaneously). And, I think, that in most of the cases, the user will not take a decision actually, but just will be informed of the existing problem with dependencies. Still, I can imagine some cases, where a decision can be taken: first of all, when it's possible to load a newer system; secondly, in a dynamic environment during experiments.
I'd rather ASDF has only one test framework, if possible one with few dependencies if at all.
I agree. If there's one already chosen, I'll stick to it. as I've said, when I've started this work, I didn't find any tests, so I used my own approach. By the way MUTEST is dependency-free.
I haven't looked at MUTEST yet. I'll have to do it soon. If you're willing to migrate all existing tests to it -- why not.
I will look at it. I think, first of all, it depends on the question, whether I will need to do something with the current tests for versioning (i.e. will the be a need to integrate that piece of code into ASDF)...
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I once dreamt that children would be taught to not accept slogans on face value, but to see through words and look for meaning or lack thereof. However, I soon realized that by the time schools teach this piece of wisdom, it may have itself become a slogan devoid of meaning, the sense of its words having drifted or been otherwise corrupted by time and vice. You need more than dead words to have people think by themselves; you need a living tradition.
Sorry, I've forgotten to address that. I agree, that supporting full Debian/RPM style versioning is better. I'm not currently familiar enough with that, so I will be thankful, if you point me to some good resource.
You can google for "rpm compare versions" and "dpkg compare versions" and things like that. You can also start with the lisp file attached, though it might not fit all the corner cases of the full specification (do you need to disambiguate if that function returns = ?).
Well, when the DEFSYSTEM form is traversed and dependencies are loaded the CURRENT implementation uses FIND-SYSTEM. That is why I worked with FIND-SYSTEM and not introduced some new construct to deal specifically with versioned dependencies, because it would have duplicated the same code (in case of not versioned ones — call FIND-SYSTEM, in case of versioned — FIND-VERSIONED-SYSTEM?)
Any call site that doesn't use VERSION can keep calling FIND-SYSTEM, and any call site that does much use a new interface anyway, so can use a different function name as well as argument list.
That sounds both complex to implement, for little value to a user.
It's already implemented, and the complexity you can judge for yourself. Considering the value to the user, you might be right. At least I'm not in the position to judge.
As for the high-level design, see other paragraphs. As for low-level coding standards, here's what I can tell from a quick glance: 1- changing incompatibly VERSION-SATISFIES isn't nice either. Please provide functions like VERSION<= VERSION-MAJOR<= VERSION-MAJOR=-MINOR<= etc. 2- instead of #+mutest tests in same file, have a different file with tests. 3- (let ((*read-eval* t)) (defun ... #.blah ...) doesn't do anything useful. The let is evaluated at execute-time, the #. at read-time.
Considering backwards incompatibility: there's no current API, I mean, those functions are not part of the API but auxiliary functions used solely in FIND-SYSTEM.
OK, so it's an internal interface. But if find-system from something straightforward becomes a monster that solves an NP-complete integer programming constraint problem, I fear we'll get more than we bargained for. And if it doesn't actually solve the version constraint problem, then it's a toy and I'd rather leave the problem to aptitude to solve. Up to now, ASDF has tried to remain simple, and I admit I did feel ambivalent about multiplying its size by three when I went from ASDF 1 to ASDF 2 (which did go noticed: at least janderson complained, and rightfully so).
I don't think proper versioning support that does the Right Thing(tm) can be added without making ASDF treble in size again, and so I'm reluctant to accept a solution that entails putting that in the basic ASDF, when what I think is a better solution can be achieved through a front-end that produces a proper source-registry, either on-line or off-line, but in any case, without growing the complexity of ASDF itself.
I propose instead that a completely different API be used, that computes and/or checks a source-registry from some specification and a database of available system versions. i.e. layer something on top of ASDF without modifying anything about ASDF proper.
Yes, that is also possible. It's just that currently ASDF has some half-baked version support and it should be either removed completely (deprecated) or improved up to usable state. I mean, that all the versions specified in current defsystem forms are hardly used by any software, that might have wanted to utilize them, and that's because of poor current implementation, I think.
My vote would be to deprecate and completely remove the current half-baked version support. I didn't do it earlier because it would have been a controversy that would only have delayed release of ASDF 2.0 without any major advantage. But now that the question is legitimately on the table, I definitely propose to get rid of that code.
It's just a matter of backwards compatibility. If we're going to change how things work, I'd rather we provide a new API and declare the old one obsolete than break backwards compatibility gratuitously.
Yes, I understand that. Well, actually, that is really not such a big issue, so FIND-SYSTEM can be left with the existing argument set (or, better, VERSION/VERSION-P arguments can be added to the tail of the optional list, which will be backwards compatible). It was more a suggestion towards a more clear API (and it's possible to change it, as it seems, noone is using the current one :) But I reiterate, that the issue is not critical at all.
I say, have a completely different function name with keyword arguments. And make it part of a separate front-end system. First implementation: export version information to dpkg format and use dpkg to solve the constraints (or same with rpm, Nix, etc.).
Also, I'm not convinced by this :VERSION interface. Version matching is not a local problem to be solved by adding :VERSION arguments to local function calls, but a global problem to be approached by collecting (in)equations about available versions, solving these inequations, and producing a source-registry (possibly pointing to a single generated link farm) as a solution.
Your solution should also work. But I believe (and my limited testing has confirmed that), that a local solution is also viable, because all the inequalities in our case boil down to the separate decisions, that can be taken only by the user himself to select, which of the conflicting versions of the system should be present in his image (as there can be only one simultaneously). And, I think, that in most of the cases, the user will not take a decision actually, but just will be informed of the existing problem with dependencies. Still, I can imagine some cases, where a decision can be taken: first of all, when it's possible to load a newer system; secondly, in a dynamic environment during experiments.
I still don't see a use-case for this interactive version-picking activity. The problem we have is known as "DLL hell". It's not something for which people want a half-assed "one question at a time" maybe-solving interaction. It's something people don't want to be doing at all. Either a solution has been found and delivered by distribution maintainers (hopefully through automated testing of candidate releases of combinations of the latest versions) and you just use that, or you're a developer trying to fix an identified problem with some recent version of a library that you want to use because of a recent bug fix or feature. In no case does anyone want to mix and match at random providing old versions one by one without knowing whether they will work together.
I haven't looked at MUTEST yet. I'll have to do it soon. If you're willing to migrate all existing tests to it -- why not.
I will look at it. I think, first of all, it depends on the question, whether I will need to do something with the current tests for versioning (i.e. will the be a need to integrate that piece of code into ASDF)...
Indeed. I don't know what others think, but I think your current code isn't desirable in ASDF. I believe it's the wrong approach, trying to salvage a doomed attempt at solving versioning through myopic interfaces instead of meaningfully addressing the issue of doing holistic version matching.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Every country has an army, either its own or a foreign one.
On 6/28/10 Jun 28 -7:58 PM, Faré wrote:
Sorry, I've forgotten to address that. I agree, that supporting full Debian/RPM style versioning is better. I'm not currently familiar enough with that, so I will be thankful, if you point me to some good resource.
You can google for "rpm compare versions" and "dpkg compare versions" and things like that. You can also start with the lisp file attached, though it might not fit all the corner cases of the full specification (do you need to disambiguate if that function returns = ?).
Well, when the DEFSYSTEM form is traversed and dependencies are loaded the CURRENT implementation uses FIND-SYSTEM. That is why I worked with FIND-SYSTEM and not introduced some new construct to deal specifically with versioned dependencies, because it would have duplicated the same code (in case of not versioned ones — call FIND-SYSTEM, in case of versioned — FIND-VERSIONED-SYSTEM?)
Any call site that doesn't use VERSION can keep calling FIND-SYSTEM, and any call site that does much use a new interface anyway, so can use a different function name as well as argument list.
That sounds both complex to implement, for little value to a user.
It's already implemented, and the complexity you can judge for yourself. Considering the value to the user, you might be right. At least I'm not in the position to judge.
As for the high-level design, see other paragraphs. As for low-level coding standards, here's what I can tell from a quick glance: 1- changing incompatibly VERSION-SATISFIES isn't nice either. Please provide functions like VERSION<= VERSION-MAJOR<= VERSION-MAJOR=-MINOR<= etc. 2- instead of #+mutest tests in same file, have a different file with tests. 3- (let ((*read-eval* t)) (defun ... #.blah ...) doesn't do anything useful. The let is evaluated at execute-time, the #. at read-time.
Considering backwards incompatibility: there's no current API, I mean, those functions are not part of the API but auxiliary functions used solely in FIND-SYSTEM.
OK, so it's an internal interface. But if find-system from something straightforward becomes a monster that solves an NP-complete integer programming constraint problem, I fear we'll get more than we bargained for. And if it doesn't actually solve the version constraint problem, then it's a toy and I'd rather leave the problem to aptitude to solve. Up to now, ASDF has tried to remain simple, and I admit I did feel ambivalent about multiplying its size by three when I went from ASDF 1 to ASDF 2 (which did go noticed: at least janderson complained, and rightfully so).
I don't think proper versioning support that does the Right Thing(tm) can be added without making ASDF treble in size again, and so I'm reluctant to accept a solution that entails putting that in the basic ASDF, when what I think is a better solution can be achieved through a front-end that produces a proper source-registry, either on-line or off-line, but in any case, without growing the complexity of ASDF itself.
I propose instead that a completely different API be used, that computes and/or checks a source-registry from some specification and a database of available system versions. i.e. layer something on top of ASDF without modifying anything about ASDF proper.
Yes, that is also possible. It's just that currently ASDF has some half-baked version support and it should be either removed completely (deprecated) or improved up to usable state. I mean, that all the versions specified in current defsystem forms are hardly used by any software, that might have wanted to utilize them, and that's because of poor current implementation, I think.
My vote would be to deprecate and completely remove the current half-baked version support. I didn't do it earlier because it would have been a controversy that would only have delayed release of ASDF 2.0 without any major advantage. But now that the question is legitimately on the table, I definitely propose to get rid of that code.
I would vote against this. Half-baked though it is, that version support has been very helpful in maintaining multiple different versions of software that I work with, and has trapped several dependency failure errors that would otherwise have caused deeply cryptic errors when, e.g., our unit testing framework was compiled against the wrong version of Closer-MOP, when a large project was tested against the wrong version of the unit test framework, etc.
The half-baked version support has been in ASDF since forever, and ripping it out before providing a working replacement fails the cost/benefit tradeoff:
Cost = a bunch of safeguards we rely on vanish.
Benefit = mild aesthetic satisfaction.
Please don't! ;-)
Best, r
Robert,
That's why I've started developing this topic of improving version support in ASDF (and not elsewhere), because if versions need to stay there, they preferably should be only there to adhere to the DRY principle, and if they are only there, they need to be supported well :)
Yet, I agree with Faré, that it's much easier to perform dependency management separately, and, if we go further along this line, completely take it out of ASDF and leave ASDF just as a build tool. Although that is highly unlikely to happen :)
Cheers, Vsevolod
On Tue, Jun 29, 2010 at 11:07 PM, Robert Goldman rpgoldman@sift.infowrote:
On 6/28/10 Jun 28 -7:58 PM, Faré wrote:
Sorry, I've forgotten to address that. I agree, that supporting full Debian/RPM style versioning is better. I'm not currently familiar
enough
with that, so I will be thankful, if you point me to some good resource.
You can google for "rpm compare versions" and "dpkg compare versions" and things like that. You can also start with the lisp file attached, though it might not fit all the corner cases of the full specification (do you need to disambiguate if that function returns = ?).
Well, when the DEFSYSTEM form is traversed and dependencies are loaded
the
CURRENT implementation uses FIND-SYSTEM. That is why I worked with FIND-SYSTEM and not introduced some new construct to deal specifically
with
versioned dependencies, because it would have duplicated the same code
(in
case of not versioned ones — call FIND-SYSTEM, in case of versioned — FIND-VERSIONED-SYSTEM?)
Any call site that doesn't use VERSION can keep calling FIND-SYSTEM, and any call site that does much use a new interface anyway, so can use a different function name as well as argument list.
That sounds both complex to implement, for little value to a user.
It's already implemented, and the complexity you can judge for yourself. Considering the value to the user, you might be right. At least I'm not
in
the position to judge.
As for the high-level design, see other paragraphs. As for low-level coding standards, here's what I can tell from a quick glance: 1- changing incompatibly VERSION-SATISFIES isn't nice either. Please provide functions like VERSION<= VERSION-MAJOR<= VERSION-MAJOR=-MINOR<= etc. 2- instead of #+mutest tests in same file, have a different file with
tests.
3- (let ((*read-eval* t)) (defun ... #.blah ...) doesn't do anything useful. The let is evaluated at execute-time, the #. at read-time.
Considering backwards incompatibility: there's no current API, I mean,
those
functions are not part of the API but auxiliary functions used solely in FIND-SYSTEM.
OK, so it's an internal interface. But if find-system from something straightforward becomes a monster that solves an NP-complete integer programming constraint problem, I fear we'll get more than we bargained for. And if it doesn't actually solve the version constraint problem, then it's a toy and I'd rather leave the problem to aptitude to solve. Up to now, ASDF has tried to remain simple, and I admit I did feel ambivalent about multiplying its size by three when I went from ASDF 1 to ASDF 2 (which did go noticed: at least janderson complained, and rightfully so).
I don't think proper versioning support that does the Right Thing(tm) can be added without making ASDF treble in size again, and so I'm reluctant to accept a solution that entails putting that in the basic ASDF, when what I think is a better solution can be achieved through a front-end that produces a proper source-registry, either on-line or off-line, but in any case, without growing the complexity of ASDF itself.
I propose instead that a completely different API be used, that
computes
and/or checks a source-registry from some specification and a database of available system versions. i.e. layer something on top of ASDF without modifying anything about ASDF proper.
Yes, that is also possible. It's just that currently ASDF has some half-baked version support and it should be either removed completely (deprecated) or improved up to usable state. I mean, that all the
versions
specified in current defsystem forms are hardly used by any software,
that
might have wanted to utilize them, and that's because of poor current implementation, I think.
My vote would be to deprecate and completely remove the current half-baked version support. I didn't do it earlier because it would have been a controversy that would only have delayed release of ASDF 2.0 without any major advantage. But now that the question is legitimately on the table, I definitely propose to get rid of that code.
I would vote against this. Half-baked though it is, that version support has been very helpful in maintaining multiple different versions of software that I work with, and has trapped several dependency failure errors that would otherwise have caused deeply cryptic errors when, e.g., our unit testing framework was compiled against the wrong version of Closer-MOP, when a large project was tested against the wrong version of the unit test framework, etc.
The half-baked version support has been in ASDF since forever, and ripping it out before providing a working replacement fails the cost/benefit tradeoff:
Cost = a bunch of safeguards we rely on vanish.
Benefit = mild aesthetic satisfaction.
Please don't! ;-)
Best, r
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 6/29/10 Jun 29 -3:13 PM, Vsevolod Dyomkin wrote:
Robert,
That's why I've started developing this topic of improving version support in ASDF (and not elsewhere), because if versions need to stay there, they preferably should be only there to adhere to the DRY principle, and if they are only there, they need to be supported well :)
Yet, I agree with Faré, that it's much easier to perform dependency management separately, and, if we go further along this line, completely take it out of ASDF and leave ASDF just as a build tool. Although that is highly unlikely to happen :)
Here I think I disagree with Fare. I think a build tool needs to "know" when dependencies are broken, and having it try to blindly load systems that are named the same, but that are of the wrong version, seems deeply undesirable to me.
To be honest, I don't think it's particularly helpful to think of ASDF as a "build tool." I think that, given CL's nature as a dynamic language, it's more productive to think of ASDF as a tool for loading software *and maintaining consistency of the lisp image*. ASDF must react to changing states of systems within a long-term running lisp session, which is very different from the much simpler task that must be performed by make.
Even taking that into account, I think that it's possible that having make be only a simple build tool may not be ideal. I'm sure we've all had one of those experiences where we thrashed about and lost a bunch of time because of version skew when building a system through make. For that matter, configure is essentially an expert system that tries to guess, based on various probes, whether version dependencies are satisfied...
best, r
On Tue, Jun 29, 2010 at 11:31 PM, Robert Goldman rpgoldman@sift.infowrote:
On 6/29/10 Jun 29 -3:13 PM, Vsevolod Dyomkin wrote:
Robert,
That's why I've started developing this topic of improving version support in ASDF (and not elsewhere), because if versions need to stay there, they preferably should be only there to adhere to the DRY principle, and if they are only there, they need to be supported well :)
Yet, I agree with Faré, that it's much easier to perform dependency management separately, and, if we go further along this line, completely take it out of ASDF and leave ASDF just as a build tool. Although that is highly unlikely to happen :)
Here I think I disagree with Fare. I think a build tool needs to "know" when dependencies are broken, and having it try to blindly load systems that are named the same, but that are of the wrong version, seems deeply undesirable to me.
To be honest, I don't think it's particularly helpful to think of ASDF as a "build tool." I think that, given CL's nature as a dynamic language, it's more productive to think of ASDF as a tool for loading software *and maintaining consistency of the lisp image*.
That's what I had also had in mind, when figuring out how to solve dependency conflicts.
ASDF must react to changing states of systems within a long-term running lisp session, which is very different from the much simpler task that must be performed by make.
Even taking that into account, I think that it's possible that having make be only a simple build tool may not be ideal. I'm sure we've all had one of those experiences where we thrashed about and lost a bunch of time because of version skew when building a system through make. For that matter, configure is essentially an expert system that tries to guess, based on various probes, whether version dependencies are satisfied...
best, r
On 29 June 2010 16:31, Robert Goldman rpgoldman@sift.info wrote:
Here I think I disagree with Fare. I think a build tool needs to "know" when dependencies are broken, and having it try to blindly load systems that are named the same, but that are of the wrong version, seems deeply undesirable to me.
I don't think we really disagree all that much. It's good that ASDF should check that systems being used are indeed compatible. But it doesn't and shouldn't try to resolve compatibility constraints amongst a pool of available systems. It picks the one and only configured system with a given name and checks that it's indeed the expected version. If the constraint language is made richer, it will be nice if ASDF can keep doing checking. But I think it's a very bad design to ever try to add the constraint resolution in ASDF itself.
To be honest, I don't think it's particularly helpful to think of ASDF as a "build tool." I think that, given CL's nature as a dynamic language, it's more productive to think of ASDF as a tool for loading software *and maintaining consistency of the lisp image*. ASDF must react to changing states of systems within a long-term running lisp session, which is very different from the much simpler task that must be performed by make.
If only... Unhappily, my experience with making ASDF itself upgradable has taught me that CL is very ill-suited to code upgrade, and that there's no easy reliable modification you can make to the image besides adding new code. So no real "change of state", only "building".
Even taking that into account, I think that it's possible that having make be only a simple build tool may not be ideal. I'm sure we've all had one of those experiences where we thrashed about and lost a bunch of time because of version skew when building a system through make. For that matter, configure is essentially an expert system that tries to guess, based on various probes, whether version dependencies are satisfied...
dpkg can do much more than that. It can actually do the NP-complete constraint solving.
--#f He who says he will die for a cause will probably lie for it and may kill for it. — John McCarthy
On 6/29/10 Jun 29 -4:47 PM, Faré wrote:
On 29 June 2010 16:31, Robert Goldman rpgoldman@sift.info wrote:
Here I think I disagree with Fare. I think a build tool needs to "know" when dependencies are broken, and having it try to blindly load systems that are named the same, but that are of the wrong version, seems deeply undesirable to me.
I don't think we really disagree all that much. It's good that ASDF should check that systems being used are indeed compatible. But it doesn't and shouldn't try to resolve compatibility constraints amongst a pool of available systems. It picks the one and only configured system with a given name and checks that it's indeed the expected version. If the constraint language is made richer, it will be nice if ASDF can keep doing checking. But I think it's a very bad design to ever try to add the constraint resolution in ASDF itself.
Yes, in that case, I think we DO agree. I don't think that one can do much constraint resolution in ASDF proper, because you don't know whether you are about to load some other system that requires a different version.
Well, I suppose one could do this, and then fail if you have a version conflict, but I doubt it's really worth the trouble, because to choose the optimal version of some library X, you would have to be able to look ahead into the future and guess the full set of future loads that might exert version constraints upon library X. I find it hard to believe that one can effectively solve this problem, or that it is worth the trouble. I would bet that a low-tech solution like ours, in which one manages different sets of asdf:*central-registry* values (I think your configuration files do this; our earlier solution does it by a find-like search for asd files over sets of directories), where the programmer chooses sets of library locations, and ASDF just checks for consistency, is more feasible.
As an aside: In my fantasy world, we have something like Ron Garrett's lexically scoped packages, thus allowing systems X and Y to coexist, even if they need conflicting versions of library Z. But that's a fantasy. I don't see any prospect of getting from the CL I use today to that world...
cheers, r
On 6/28/10 Jun 28 -5:22 PM, Vsevolod Dyomkin wrote:
On Tue, Jun 29, 2010 at 1:00 AM, Faré <fahree@gmail.com mailto:fahree@gmail.com> wrote:
I propose instead that a completely different API be used, that computes and/or checks a source-registry from some specification and a database of available system versions. i.e. layer something on top of ASDF without modifying anything about ASDF proper.Yes, that is also possible. It's just that currently ASDF has some half-baked version support and it should be either removed completely (deprecated) or improved up to usable state. I mean, that all the versions specified in current defsystem forms are hardly used by any software, that might have wanted to utilize them, and that's because of poor current implementation, I think.
I think it's also because of poor current documentation (and poor documentation reading :->).
Where I work we use :version extensively, and I have discussed this with several people who provide libraries, and encouraged them to comply with the de facto x.y.z versioning standard. The library maintainers have all been very good about adding versioning information, but several have expressed a lack of understanding of how ASDF :version works.
Until recently, you really needed to read the ASDF source to discover how :version worked, and that is, IMO, too high a barrier to put.
Best, r
On 6/28/10 Jun 28 -12:48 AM, Vsevolod Dyomkin wrote:
Hi!
[...snip...]
A final note about versioning: I needed to use pre-reading of ASD files in order to know their versions without arising version conflicts. This works, except for the fact, that READ-EVAL is turned off in the process, so such version specifiers as:
- :version #.*hunchentoot-version*
- :version #.(with-open-file (vers (merge-pathnames "version.lisp-expr"
*load-truename*)) (read vers)) do not produce expected results and are treated as empty versions. There will be a need to make a note about that to library developers.
This is a substantial revision of the contract between the ASDF system author and ASDF, and I suggest that we *NOT* make this change in this local context.
There has been a substantial amount of discussion on moving ASDF system definitions to a more declarative representation, particularly one that could be safely processed by READ, without EVAL. Both Juanjo and James Anderson, IIRC, have pressed for a change in this direction for reasons other than fixing versioning.
As part of this discussion, there have been mentions of specific revisions to DEFSYSTEM intended to make it safely readable without sacrificing too much of ASDF's expressive power.
I would like to suggest that we have an online discussion (and, ideally some kind of hybrid on- off-line discussion possibly affiliated with ILC) of this matter among ALL the people interested in seeing ASDF move to a readable (as opposed to only a LOADable) form of system definition, rather than rush into it in this way.
ASDF is a critical piece of the CL world's development infrastructure, and large-scale modifications such as this one cannot be made hastily.
Best, Robert
-
Faré -
Robert Goldman -
Vsevolod Dyomkin