[asdf-devel] component-property
Dear Red, I see that you're using component-property to add a website property to your .asd files. On the one hand, I am deprecating component-property in ASDF3, so you should stop using that. For the sake of backward-compatibility, I'll add dummy methods so your existing code keeps compiling, but they won't do anything if I can get away with it. On the other hand, now is a good time for me to add new slots to system objects. I will add a website slot in 2.26.171, though you'll have to #+asdf3 :website #+asdf3 "http://xxx" for now. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The Keyboard is mightier than the Death Ray...
"Fare" == Far <Far> writes:
Fare> Dear Red, Fare> I see that you're using component-property to add a website property Fare> to your .asd files. Fare> On the one hand, I am deprecating component-property in ASDF3, Fare> so you should stop using that. For the sake of backward-compatibility, Fare> I'll add dummy methods so your existing code keeps compiling, but Fare> they won't do anything if I can get away with it. Fare> On the other hand, now is a good time for me to add new slots to system objects. Fare> I will add a website slot in 2.26.171, though you'll have to Fare> #+asdf3 :website #+asdf3 "http://xxx" for now. Does :website do anything other than record that info? If not, then why not use :url? Ray
Fare> On the other hand, now is a good time for me to add new slots to system objects. Fare> I will add a website slot in 2.26.171, though you'll have to Fare> #+asdf3 :website #+asdf3 "http://xxx" for now.
Does :website do anything other than record that info? If not, then why not use :url?
I actually pushed 2.26.171 without adding any such slot yet. I'm open to debate on naming things. And I reinstantiated the previous properties interface for backward compatibility, until everyone adopts the new solution (which may take years). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The main difference between a computer salesman and a used car salesman is that the used car salesman can probably drive and knows when he's lying. - Peter da Silva
On the one hand, I am deprecating component-property in ASDF3,
Why? What will be the new mechanism for what component-property provides?
I propose that any data that component-property is actually used for should be in appropriate slots of the system. I will gather a list from things in quicklisp. As for extensibility, there is already defclass for that. Or comments, when the meta-data isn't for machine consumption. This will not happen for ASDF 2.27, but hopefully for 3.0. Even after it happens, a compatibility layer will be provided for old code; but its use for new code will be strongly discouraged, e.g. by droppng the data that doesn't fit the backward-compatibility schema, and/or issuing an error if the system is not whitelisted. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Economics is not about goods and services; it is about human choice and action. — Ludwig von Mises
Faré <fahree@gmail.com> writes:
On the one hand, I am deprecating component-property in ASDF3,
Why? What will be the new mechanism for what component-property provides?
I propose that any data that component-property is actually used for should be in appropriate slots of the system.
This will introduce a new round of synchronization headaches whenever a new slot is added. The existing mechanism is forward and backward compatible indefinitely. Zach
On the one hand, I am deprecating component-property in ASDF3,
Why? What will be the new mechanism for what component-property provides?
I propose that any data that component-property is actually used for should be in appropriate slots of the system.
This will introduce a new round of synchronization headaches whenever a new slot is added. The existing mechanism is forward and backward compatible indefinitely.
Synchronization is NOT necessary to add new slots. If you want a new slot, just create a new class with that slot, and use both :defsystem-depends-on and :class in your defsystem form. This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but it works quite well since ASDF 2.016 from June 2011 and later. Then, a year after your slot gets merged into asdf:system, you can stop using your defsystem-depends-on. The properties mechanism is already totally and irremediably useless. Automation across systems is impossible unless everyone agrees on a schema, or you somehow merge the zillions of possible ad-hoc schemas; but properties actually make synchronization *harder* than lack thereof, by making it cheaper to diverge and more expensive to converge. Properties without a synchronized schema are useless within a single system, where it is easier, safer and more powerful to just directly store data in a Lisp variable rather than in the properties. In other words, properties not only do not serve the purpose they look like they are addressing, but cannot possibly serve any purpose. They are a lure and a waste of everyone's time — an attractive nuisance. I propose they be replaced by the real thing, i.e. agreeing on a schema. Before we do, we would be well inspired to look at similar metadata schemas from Debian, RPM, Hackage, PLaneT, etc. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Failure is the opportunity to begin again, more intelligently. — Henry Ford, who had two flops before founding Ford Motor Co.
Faré <fahree@gmail.com> writes:
On the one hand, I am deprecating component-property in ASDF3,
Why? What will be the new mechanism for what component-property provides?
I propose that any data that component-property is actually used for should be in appropriate slots of the system.
This will introduce a new round of synchronization headaches whenever a new slot is added. The existing mechanism is forward and backward compatible indefinitely.
Synchronization is NOT necessary to add new slots. If you want a new slot, just create a new class with that slot, and use both :defsystem-depends-on and :class in your defsystem form. This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but it works quite well since ASDF 2.016 from June 2011 and later. Then, a year after your slot gets merged into asdf:system, you can stop using your defsystem-depends-on.
Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques.
The properties mechanism is already totally and irremediably useless. Automation across systems is impossible unless everyone agrees on a schema, or you somehow merge the zillions of possible ad-hoc schemas; but properties actually make synchronization *harder* than lack thereof, by making it cheaper to diverge and more expensive to converge. Properties without a synchronized schema are useless within a single system, where it is easier, safer and more powerful to just directly store data in a Lisp variable rather than in the properties.
In other words, properties not only do not serve the purpose they look like they are addressing, but cannot possibly serve any purpose. They are a lure and a waste of everyone's time — an attractive nuisance.
I think it would be pretty easy to get everyone to agree on a schema for properties, and it would be useful to do so. Zach
Synchronization is NOT necessary to add new slots. If you want a new slot, just create a new class with that slot, and use both :defsystem-depends-on and :class in your defsystem form. This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but it works quite well since ASDF 2.016 from June 2011 and later. Then, a year after your slot gets merged into asdf:system, you can stop using your defsystem-depends-on.
Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques.
There is no compatibility problem whatsoever with adding optional slots. And I *will* severely cripple the properties slot, then remove it eventually, but not until after everyone has moved away from it for a year or two.
The properties mechanism is already totally and irremediably useless. Automation across systems is impossible unless everyone agrees on a schema, or you somehow merge the zillions of possible ad-hoc schemas; but properties actually make synchronization *harder* than lack thereof, by making it cheaper to diverge and more expensive to converge. Properties without a synchronized schema are useless within a single system, where it is easier, safer and more powerful to just directly store data in a Lisp variable rather than in the properties.
In other words, properties not only do not serve the purpose they look like they are addressing, but cannot possibly serve any purpose. They are a lure and a waste of everyone's time — an attractive nuisance.
I think it would be pretty easy to get everyone to agree on a schema for properties, and it would be useful to do so.
For the same price, we can agree on a schema, add it to defclass system, and get rid of the attractive nuisance that is component-properties. Silently incompatible is not the same as compatible. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org War does not determine who is right — only who is left. — Bertrand Russell
Faré <fahree@gmail.com> writes:
Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques.
There is no compatibility problem whatsoever with adding optional slots.
I just tried, and got this: Error while trying to load definition for system wwwoops from pathname /home/xach/src/lisp/wwwoops/wwwoops.asd: Invalid initialization argument: :WEBSITE in call for class #<STANDARD-CLASS ASDF:SYSTEM>. [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR] There *is* a compatibility problem. Zach
Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques.
There is no compatibility problem whatsoever with adding optional slots.
I just tried, and got this:
Error while trying to load definition for system wwwoops from pathname /home/xach/src/lisp/wwwoops/wwwoops.asd: Invalid initialization argument: :WEBSITE in call for class #<STANDARD-CLASS ASDF:SYSTEM>. [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR]
There *is* a compatibility problem.
I haven't added the slots yet, so of course it won't work. As for disabling properties on old versions of ASDF that don't actually support them, that's what #+asdf3 is for, just like #+asdf2 before it. Hopefully, two years from now we can assume everyone has moved from ASDF2 to ASDF3, just like today we can safely assume no one uses ASDF1 anymore. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Oignez villain, il vous poindra ; poignez villain, il vous oindra. — Rabelais
Faré <fahree@gmail.com> writes:
Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques.
There is no compatibility problem whatsoever with adding optional slots.
I just tried, and got this:
Error while trying to load definition for system wwwoops from pathname /home/xach/src/lisp/wwwoops/wwwoops.asd: Invalid initialization argument: :WEBSITE in call for class #<STANDARD-CLASS ASDF:SYSTEM>. [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR]
There *is* a compatibility problem.
I haven't added the slots yet, so of course it won't work. As for disabling properties on old versions of ASDF that don't actually support them, that's what #+asdf3 is for, just like #+asdf2 before it.
When it is time to add support for a bug-tracker-url slot, will there be a feature for that? Or will that be done via subclassing? Zach
I haven't added the slots yet, so of course it won't work. As for disabling properties on old versions of ASDF that don't actually support them, that's what #+asdf3 is for, just like #+asdf2 before it.
When it is time to add support for a bug-tracker-url slot, will there be a feature for that? Or will that be done via subclassing?
Now is a good time to request such features, before ASDF 3 is actually released. After it is released, and until another major release follows, subclassing will be the recommended way. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The politicians have a most touching faith in technology — that it can make up for any dumb thing the politicians decide to do. — John McCarthy
Faré <fahree@gmail.com> writes:
I haven't added the slots yet, so of course it won't work. As for disabling properties on old versions of ASDF that don't actually support them, that's what #+asdf3 is for, just like #+asdf2 before it.
When it is time to add support for a bug-tracker-url slot, will there be a feature for that? Or will that be done via subclassing?
Now is a good time to request such features, before ASDF 3 is actually released. After it is released, and until another major release follows, subclassing will be the recommended way.
I request a slot called "properties" that can hold arbitrary key/value data. Zach
I request a slot called "properties" that can hold arbitrary key/value data.
If it's arbitrary, it's not usable from one system to the other, and thus serves no purpose. Are you the same Zach Beane who refuses to use system-relative-pathname to find files relative to the source directory? These two attitudes seem to me to be inconsistent simultaneously with each other and with reality. On the one hand, you promote the use of the system objects to hold information that cannot be acted upon using any uniform interface across systems, rather than per-system variables, even though only system-specific functions can ever hope to make use of them. On the other hand, here is a uniform interface to locating system-relative information, and you don't want to use it, instead reinventing one new variable per system. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Government's view of the economy could be summed up in a few short phrases : If it moves, tax it. If it keeps moving, regulate it. And if it stops moving, subsidize it. — Ronald Reagan (1986)
Faré <fahree@gmail.com> writes:
I request a slot called "properties" that can hold arbitrary key/value data.
If it's arbitrary, it's not usable from one system to the other, and thus serves no purpose.
I don't understand this, sorry. Imagine that there was a community desire to provide, in a system, the answer to the question "Where is the best place to go to report bugs for this system?" It is possible, today, to choose a key (or set of keys) for a property stored in the system, and for authors who wish to participate to adopt the convention, and for some tool to gather this information and provide it in a useful way. I don't see how this is not usable from one system to another. It does not require reader conditionalization, subclassing, or ASDF upgrades. It can be expanded and changed without expansions or changes to ASDF. It works with past versions of ASDF, present versions of ASDF, and until today, I thought it would work in future versions of ASDF. I'm not sure why this is an undesirable feature that must be removed from ASDF. Zach
: Xach : Faré : Xach
I request a slot called "properties" that can hold arbitrary key/value data.
If it's arbitrary, it's not usable from one system to the other, and thus serves no purpose.
I don't understand this, sorry.
Imagine that there was a community desire to provide, in a system, the answer to the question "Where is the best place to go to report bugs for this system?"
Doesn't require a lot of imagination. Then we add a new slot for that.
It is possible, today, to choose a key (or set of keys) for a property stored in the system, and for authors who wish to participate to adopt the convention, and for some tool to gather this information and provide it in a useful way.
There's already a perfectly fine feature for free-form metadata that follows loose conventions impossible to process automatically. It's called comments. Contrariwise, class slots are supposed to hold information suitable for automation following sufficiently agreed-upon protocols.
I don't see how this is not usable from one system to another.
Different names for the same thing, or same name for different things. Automation is hell if possible at all. A disservice to the community.
It does not require reader conditionalization, subclassing, or ASDF upgrades. It can be expanded and changed without expansions or changes to ASDF. It works with past versions of ASDF, present versions of ASDF, and until today, I thought it would work in future versions of ASDF.
It still requires agreement to an actual specified protocol to be useful, but it creates the false sense that cooperation is possible without such. Out of the existing uses of :properties, the only properties that are usable by more than one system are the albert things. Interestingly, they are not a protocol allowing for multiple software to cooperate, but only the internals of a single system, and would be better served by an albert-system subclass of system. None of these properties otherwise "works" in any meaningful way as a convention followed by multiple parties. Remarkably, automation still requires software to be written, and does not retroactively happen in old versions of the software.
I'm not sure why this is an undesirable feature that must be removed from ASDF.
I don't see any feature being removed. I see features being added, and a bug being removed that lures developers into believing they are cooperating with others when actually they aren't. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There are a thousand hacking at the branches of evil to one who is striking at the root. — Thoreau
In 2.26.174, I added the following initargs to system with system-FOO accessors. I also added an :initform nil to all those optional metadata slots and previous ones. :long-name "Another System Definition Facility" :website-url "http://common-lisp.net/projects/asdf/" :bug-tracker-url "https://launchpad.net/asdf/" :developers-email "asdf-devel@common-lisp.net" :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git") If there is more automatically-processable metadata for which you'd like a defined slot in ASDF3, now is the time to speak. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What a lot of trouble to prove in political economy that two and two make four; and if you succeed in doing so, people cry, 'It is so clear that it is boring.' Then they vote as if you had never proved anything at all. — Frederic Bastiat, "What Is Seen and What is Not Seen", 1850
Dear Red, as a follow up to my previous email, I eventually added in 2.26.174 the following initargs to defclass system, with system-FOO accessors. :long-name "Another System Definition Facility" :website-url "http://common-lisp.net/projects/asdf/" :bug-tracker-url "https://launchpad.net/asdf/" :developers-email "asdf-devel@common-lisp.net" :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git") The down side is that until ASDF2 is end-of-lifed, you'll have to #+asdf3 all these things either individually or together via e.g. (eval `(defsystem ... #+asdf3 ,@'(...) ...), (defsystem ... . #.(or #+asdf3 '(...)) or some other such ugliness. The upside is that with this standardization, odds are higher that this metadata can be used to automate processing of some sort across systems. If there are more slots that you need, now is a good time to suggest them. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What a lot of trouble to prove in political economy that two and two make four; and if you succeed in doing so, people cry, 'It is so clear that it is boring.' Then they vote as if you had never proved anything at all. — Frederic Bastiat, "What Is Seen and What is Not Seen", 1850
After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27: :long-name "Another System Definition Facility" :homepage "http://common-lisp.net/projects/asdf/" :bug-tracker "https://launchpad.net/asdf/" :mailto "asdf-devel@common-lisp.net" :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git") —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Hopefully, they ban not just gay marriage, but straight marriage too, and at last we have separation of state and marriage.
"Fare" == Far <Far> writes:
Fare> After discussion with people on #lisp and via private chat, I decided Fare> to use a shorter name. Here is what was released in 2.27: Fare> :long-name "Another System Definition Facility" Fare> :homepage "http://common-lisp.net/projects/asdf/" Fare> :bug-tracker "https://launchpad.net/asdf/" Fare> :mailto "asdf-devel@common-lisp.net" Fare> :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git") Are the valid key values for :source-control specified? I guess they're all pretty obvious like :git, :cvs, :darcs, etc. But mercurial is a bit odd. Is it :mercurial or :hg? Or maybe it doesn't really matter? Ray
Raymond Toy <toy.raymond@gmail.com> writes:
"Fare" == Far <Far> writes:
Fare> After discussion with people on #lisp and via private chat, I decided Fare> to use a shorter name. Here is what was released in 2.27:
Fare> :long-name "Another System Definition Facility" Fare> :homepage "http://common-lisp.net/projects/asdf/" Fare> :bug-tracker "https://launchpad.net/asdf/" Fare> :mailto "asdf-devel@common-lisp.net" Fare> :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git")
Are the valid key values for :source-control specified? I guess they're all pretty obvious like :git, :cvs, :darcs, etc. But mercurial is a bit odd. Is it :mercurial or :hg?
:svn or :subversion ? Are :sccs and :rcs supported? -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
Raymond Toy <toy.raymond@gmail.com> writes:
> "Fare" == Far <Far> writes:
Fare> After discussion with people on #lisp and via private chat, I decided Fare> to use a shorter name. Here is what was released in 2.27:
Fare> :long-name "Another System Definition Facility" Fare> :homepage "http://common-lisp.net/projects/asdf/" Fare> :bug-tracker "https://launchpad.net/asdf/" Fare> :mailto "asdf-devel@common-lisp.net" Fare> :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git")
Are the valid key values for :source-control specified? I guess they're all pretty obvious like :git, :cvs, :darcs, etc. But mercurial is a bit odd. Is it :mercurial or :hg?
:svn or :subversion ?
Are :sccs and :rcs supported?
And :tarball ? But actually nowadays, most of the asdf systems are obtained thru quicklisp. Should quicklisp update the source url? Or should we add a :obtained-from-url ? -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
01.02.2013, 23:23, "Faré" <fahree@gmail.com>:
After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27:
:long-name "Another System Definition Facility" :homepage "http://common-lisp.net/projects/asdf/" :bug-tracker "https://launchpad.net/asdf/" :mailto "asdf-devel@common-lisp.net" :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git")
Another useful slot would be :purpose, it could specify what the library is: web server, db client, image processing library, data-structures library, etc. The values in this slots are tags from some specified taxonomy. To avoid creating the taxonomy from scratch we could start for example with the tag tree from cl-user.net. In in the future we could want to improve the taxonomy. If the new improved taxonomy is incompatible with the old one, we can then introduce new slot, :purpose2, specifying that it can hold values from new taxonomy. I think this is an idea for future, it's probably too big to be in the scope of ASDF3
On Fri, Feb 1, 2013 at 8:19 PM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
01.02.2013, 23:23, "Faré" <fahree@gmail.com>:
After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27:
:long-name "Another System Definition Facility" :homepage "http://common-lisp.net/projects/asdf/" :bug-tracker "https://launchpad.net/asdf/" :mailto "asdf-devel@common-lisp.net" :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git")
Another useful slot would be :purpose, it could specify what the library is: web server, db client, image processing library, data-structures library, etc.
The values in this slots are tags from some specified taxonomy. To avoid creating the taxonomy from scratch we could start for example with the tag tree from cl-user.net.
In in the future we could want to improve the taxonomy. If the new improved taxonomy is incompatible with the old one, we can then introduce new slot, :purpose2, specifying that it can hold values from new taxonomy.
I think this is an idea for future, it's probably too big to be in the scope of ASDF3 s Why not. And if some people end up actually using component-property for such useful purpose, or otherwise make successful use of it, I am willing to reconsider the deprecation of component-property, and/or my successor will.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No matter what language you use, a Sufficiently Smart Compiler(TM) will be able to find an efficient implementation for whatever apparently difficult problem you specify. However, a Sufficiently Smart Compiler(TM) for arbitrary problems is itself an AI-complete problem.
FWIW, here's the list of properties in LibCL before it died. An incomplete readme is attached. A few fields were specific to LIBCL (most belong in ASDF properties); I was bootstrapping this on the side out of necessity. Hasn't a similar effort been started in Quicklisp? (:name "" :website "" ;:license :bsl :short-desc "" :maintainer () :docpath "" :tags () :todo nil :provides () :load-unless nil :version "" :date "" :source ()) Here's an example of what I wrote for Hunchentoot. (:name "Hunchentoot" :website "http://weitz.de/hunchentoot/" :license :bsd :short-desc "web server" :maintainer ("http://common-lisp.net/mailman/listinfo/tbnl-devel" "http://weitz.de/patches.html") :docpath "" :tags (:web) :todo nil :provides () :load-unless nil :version "" :date "2010-08-29" :source (:svn "svn://bknr.net/svn/trunk/thirdparty/hunchentoot" 4603)) - Daniel
02.02.2013, 05:29, "Faré" <fahree@gmail.com>:
On Fri, Feb 1, 2013 at 8:19 PM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
01.02.2013, 23:23, "Faré" <fahree@gmail.com>:
After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27:
:long-name "Another System Definition Facility" :homepage "http://common-lisp.net/projects/asdf/" :bug-tracker "https://launchpad.net/asdf/" :mailto "asdf-devel@common-lisp.net" :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git") Another useful slot would be :purpose, it could specify what the library is: web server, db client, image processing library, data-structures library, etc.
The values in this slots are tags from some specified taxonomy. To avoid creating the taxonomy from scratch we could start for example with the tag tree from cl-user.net.
In in the future we could want to improve the taxonomy. If the new improved taxonomy is incompatible with the old one, we can then introduce new slot, :purpose2, specifying that it can hold values from new taxonomy.
I think this is an idea for future, it's probably too big to be in the scope of ASDF3 s
Why not. And if some people end up actually using component-property for such useful purpose, or otherwise make successful use of it, I am willing to reconsider the deprecation of component-property, and/or my successor will.
Maybe it's clear already, but I am not arguing for/against component-property. Just share this idea because it is now being discussed what metadata attributes are useful.
Faré <fahree@gmail.com> writes:
I'm not sure why this is an undesirable feature that must be removed from ASDF.
I don't see any feature being removed. I see features being added, and a bug being removed that lures developers into believing they are cooperating with others when actually they aren't.
Fair enough. If I need this in the future, I will find some other mechanism. Zach
I did an analysis of how system properties are used in Quicklisp systems, and this suggests that the following initargs be added: :website-url <=== widely requested. the URL suffix makes it less ambiguous. :bug-tracker-url <=== Zach's request that makes a *whole* lot of sense :development-email <=== More actionable name than :author-email. Or maybe just use mailto: URL in bug-tracker-url? :long-name <=== we have :long-description already, so why not? I believe some kind of :source-control slot might be useful, though between SVN, GIT, Mercurial, etc., there is no common URL pattern, so we'd have to specify some structure. Either a list of `(,vcs-keyword ,@url+options) or a command to checkout / clone the repository to be parsed, or something. Here are the uses of component properties in Quicklisp systems: asd's that directly use asdf:component-property: *** yaclml => :features <=== property for version comparison. See arnesi below. *** amazon-ecs => :website <=== Yes, need to be added to ASDF 3. *** hemlock.asd => :last-loaded-as-source <=== bad implementation of latin1 encodings with lifted from ASDF 1's bad implementation of load-source-op. Let's just use asdf-encodings for that, and/or use UTF-8, furgossake. asd's that use :properties in defsystem: *** arnesi, arnesi+ => :features <=== misguided property used for version comparison and pseudo #+features version comparison should use :version. The pseudo-features should probably be replaced by either having separate systems or actual features, depending on their use pattern. If actually useful, create a subclass with a :component-features initarg. *** lkcas, thopter => :long-name <=== used by the Makefile through component-property. I could add that to defclass system, or he could use a subclass. *** cl-irc cliki-bot rss cl-syslog com.informatimago.clext com.informatimago.clisp com.informatimago.clmisc com.informatimago.common-lisp.arithmetic om.informatimago.common-lisp.bank com.informatimago.common-lisp.cesarum com.informatimago.common-lisp com.informatimago.common-lisp.csv com.informatimago.common-lisp.cxx com.informatimago.common-lisp.data-encoding com.informatimago.common-lisp.diagram com.informatimago.common-lisp.ed com.informatimago.common-lisp.graphviz com.informatimago.common-lisp.heap com.informatimago.common-lisp.html-base com.informatimago.common-lisp.html-generator com.informatimago.common-lisp.html-parser com.informatimago.common-lisp.http com.informatimago.common-lisp.interactive com.informatimago.common-lisp.invoice com.informatimago.common-lisp.lisp com.informatimago.common-lisp.lisp.ibcl com.informatimago.common-lisp.lisp.stepper com.informatimago.common-lisp.lisp-reader com.informatimago.common-lisp.lisp-sexp com.informatimago.common-lisp.lisp-text com.informatimago.common-lisp.parser com.informatimago.common-lisp.picture com.informatimago.common-lisp.regexp com.informatimago.common-lisp.rfc2822 com.informatimago.common-lisp.rfc3548 com.informatimago.common-lisp.telnet com.informatimago.common-lisp.unix linc com.informatimago.lispdoc com.informatimago.lua com.informatimago.cocoa-playground com.informatimago.objcl com.informatimago.rdp com.informatimago.rdp.basic com.informatimago.rdp.basic.example com.informatimago.rdp.example com.informatimago.susv3 com.informatimago.common-lisp.tools.make-depends com.informatimago.xcode spartns xlunit => (WTF???? uninterned symbols, really?) #:author-email <=== somewhat useful piece of data #:date <=== You're never going to get anything but stale information here. (#:albert #:output-dirs) <=== An absolute pathname in a .asd? Braindamage! (#:albert #:formats) <=== should be moved to some albert-system class slots (#:albert #:docbook #:template) (#:albert #:docbook #:bgcolor) (#:albert #:docbook #:textcolor) (#:albert #:docbook #:dtd) *** portableaserve => (WTF???? The same albert thing, just incompatibly?) ("system" "author" "email") ("albert" "presentation" "output-dir") ("albert" "presentation" "formats") ("albert" "docbook" "dtd") ("albert" "docbook" "template") !! Albert should probably use its own subclass to put its information *** com.clearly-useful.generic-collection-interface => :com.clearly-useful <=== whatever you're doing, use a subclass. *** metatilities => :ait-timeout :system-applicable-p <=== same comment *** ucw ucw-core => it.bese.ucw.system::version <=== WTF? use :version instead. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "On two occasions I have been asked [by members of Parliament!], `Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." — Charles Babbage
I'm still curious as to _why_ component property is going away, not (just) how you think folks should work around its absence. thanks, Cyrus On Jan 31, 2013, at 9:10 AM, Faré <fahree@gmail.com> wrote:
On the one hand, I am deprecating component-property in ASDF3,
Why? What will be the new mechanism for what component-property provides?
I propose that any data that component-property is actually used for should be in appropriate slots of the system. I will gather a list from things in quicklisp.
As for extensibility, there is already defclass for that. Or comments, when the meta-data isn't for machine consumption.
This will not happen for ASDF 2.27, but hopefully for 3.0. Even after it happens, a compatibility layer will be provided for old code; but its use for new code will be strongly discouraged, e.g. by droppng the data that doesn't fit the backward-compatibility schema, and/or issuing an error if the system is not whitelisted.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Economics is not about goods and services; it is about human choice and action. — Ludwig von Mises
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
participants (7)
-
Anton Vodonosov -
Cyrus Harmon -
Daniel Herring -
Faré -
Pascal J. Bourguignon -
Raymond Toy -
Zach Beane