Dear Nathan,
at least as far as quicklisp-included software goes, your ironclad and nibbles seem to be the only user of ASDF's :if-component-dep-fails and :feature features. These features are a crock and I'd like to plainly remove them. In the future, I might provide a better-thought-out replacement that actually works. In the meantime, the backwards-compatible solution would be to use #+sbcl and such; yes it breaks an abstraction barrier — but at least it doesn't require ASDF itself to break its own abstraction barrier internally.
Could you "fix" your .asd's to not use these features I'd like to drop?
Does any other person who cares about ASDF cares about these features?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you make people think they're thinking, they'll love you; but if you really make them think, they'll hate you. — Don Marquis
I can probably do that, yes. Why do you say they're a crock? They're very useful for defining what's supposed to happen at a higher level than scattering #+/- about source files everywhere.
-Nathan
On Fri, Dec 14, 2012 at 12:02 PM, Faré fahree@gmail.com wrote:
Dear Nathan,
at least as far as quicklisp-included software goes, your ironclad and nibbles seem to be the only user of ASDF's :if-component-dep-fails and :feature features. These features are a crock and I'd like to plainly remove them. In the future, I might provide a better-thought-out replacement that actually works. In the meantime, the backwards-compatible solution would be to use #+sbcl and such; yes it breaks an abstraction barrier — but at least it doesn't require ASDF itself to break its own abstraction barrier internally.
Could you "fix" your .asd's to not use these features I'd like to drop?
Does any other person who cares about ASDF cares about these features?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you make people think they're thinking, they'll love you; but if you really make them think, they'll hate you. — Don Marquis
On Fri, Dec 14, 2012 at 12:15 PM, Nathan Froyd froydnj@gmail.com wrote:
I can probably do that, yes. Why do you say they're a crock? They're very useful for defining what's supposed to happen at a higher level than scattering #+/- about source files everywhere.
Oh, they serve a useful purpose, but they do it in a very roundabout way, and they break the normal meaning of the dependency graph. I also strongly dislike weakly-depends-on for the same reason, though at least if can be thought of, just like #+, as a preprocessing phase before the building of the dependency graph, rather than something that magically escapes from the graph to a magic special case in a specific traversal algorithm — what more only at traversal time, unlike what the name suggests.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A programming language is low level when its programs require attention to the irrelevant. — Alan Perlis
On 12/14/12 Dec 14 -11:02 AM, Faré wrote:
Dear Nathan,
at least as far as quicklisp-included software goes, your ironclad and nibbles seem to be the only user of ASDF's :if-component-dep-fails and :feature features. These features are a crock and I'd like to plainly remove them. In the future, I might provide a better-thought-out replacement that actually works. In the meantime, the backwards-compatible solution would be to use #+sbcl and such; yes it breaks an abstraction barrier — but at least it doesn't require ASDF itself to break its own abstraction barrier internally.
Could you "fix" your .asd's to not use these features I'd like to drop?
Does any other person who cares about ASDF cares about these features?
I think, if we remove :if-component-dep-fails and replace it with something better (a choice I heartily applaud), and also add your prepare-op, that sounds to me like a big enough change to the API to warrant calling this ASDF 3 sometime soon....
There are enough API differences that I think being able to say
#+asdf3
might be useful...
Cheers, r
rpgoldman:
I think, if we remove :if-component-dep-fails and replace it with something better (a choice I heartily applaud), and also add your prepare-op, that sounds to me like a big enough change to the API to warrant calling this ASDF 3 sometime soon....
There are enough API differences that I think being able to say
#+asdf3
might be useful...
Problem: asdf's current versioning scheme will declare that asdf 3 is incompatible with asdf 2, so anyone who tries (asdf:version-satifies "3.0" "2.26") is in for a big disappointment.
As long as we reasonably don't break compatibility, I propose we keep the asdf 2 series going indefinitely.
And if we are going to break compatibility, we know where to find xcvb, quick-build, etc.
— Question authority! — Yeah, says who?
On 12/14/12 Dec 14 -12:21 PM, Faré wrote:
rpgoldman:
I think, if we remove :if-component-dep-fails and replace it with something better (a choice I heartily applaud), and also add your prepare-op, that sounds to me like a big enough change to the API to warrant calling this ASDF 3 sometime soon....
There are enough API differences that I think being able to say
#+asdf3
might be useful...
Problem: asdf's current versioning scheme will declare that asdf 3 is incompatible with asdf 2, so anyone who tries (asdf:version-satifies "3.0" "2.26") is in for a big disappointment.
As long as we reasonably don't break compatibility, I propose we keep the asdf 2 series going indefinitely.
That's a good point.
If we are going to stick to ASDF 2 indefinitely, would it be a problem to move to an xx.yy.zz format of versioning, where delta(yy) = change in API and delta(zz) = patch?
The reason I suggest this is that it might be easier to keep track of the way in which the xx's correspond to features you need that way. Most people who are worried about whether their ASDF system definitions will work could safely ignore the zz's.
Personally, I have pretty much lost track of when features I need were added to ASDF.
Just a thought.... If it's too much trouble, don't worry about it.
Problem: asdf's current versioning scheme will declare that asdf 3 is incompatible with asdf 2, so anyone who tries (asdf:version-satifies "3.0" "2.26") is in for a big disappointment.
As long as we reasonably don't break compatibility, I propose we keep the asdf 2 series going indefinitely.
That's a good point.
If we are going to stick to ASDF 2 indefinitely, would it be a problem to move to an xx.yy.zz format of versioning, where delta(yy) = change in API and delta(zz) = patch?
The problem is what constitues a "change in API"; as long as we preserve what's documented, that can be in the eye of the beholder, and we failed to document much.
That said, I agree there should probably be a #+asdf2.27 or something, since I'm introducing some several major changes: asdf-bundle, building those who depend-on a modified system, proper timestamps, yet another complete rewrite of traverse, removal of :feature and :if-component-fails, etc.
The reason I suggest this is that it might be easier to keep track of the way in which the xx's correspond to features you need that way. Most people who are worried about whether their ASDF system definitions will work could safely ignore the zz's.
I don't think that will work any the better than now. You will still have to look at the debian/changelog or git log to see when a feature was introduced or removed.
Personally, I have pretty much lost track of when features I need were added to ASDF.
If you care to specify the proper version of asdf to depend on, the release-to-release debian/changelog and the commit-to-commit git log are here to help.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What is mind? No matter! What is matter? Never mind! — Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest
On 12/14/12 Dec 14 -3:13 PM, Faré wrote:
Personally, I have pretty much lost track of when features I need were added to ASDF.
If you care to specify the proper version of asdf to depend on, the release-to-release debian/changelog and the commit-to-commit git log are here to help.
Ah. Thanks. I don't use the debian packaged version, so it didn't occur to me to look in debian/
Any chance of promoting the changelog to the root directory?
I don't suppose symlinking works happily, especially for folks on Windows....
Having a changelog probably makes it less critical to distinguish api changes from patch releases. I have a minor feeling that it's tidier to do so, but that's probably just being obsessive.
cheers, r
On Fri, Dec 14, 2012 at 6:40 PM, Robert Goldman rpgoldman@sift.info wrote:
On 12/14/12 Dec 14 -3:13 PM, Faré wrote:
Personally, I have pretty much lost track of when features I need were added to ASDF.
If you care to specify the proper version of asdf to depend on, the release-to-release debian/changelog and the commit-to-commit git log are here to help.
Ah. Thanks. I don't use the debian packaged version, so it didn't occur to me to look in debian/
Any chance of promoting the changelog to the root directory?
No, that's where debian wants it, I don't want to do double work.
I don't suppose symlinking works happily, especially for folks on Windows....
Nope. I could include a note in the README...
Having a changelog probably makes it less critical to distinguish api changes from patch releases. I have a minor feeling that it's tidier to do so, but that's probably just being obsessive.
It's important to distinguish releases. Things break during development, some commits are checkpoints of work in progress, and more testing happens before (or sadly, after) release.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Of course, Third World leaders love you. By ascribing third world ills to First World sins, you absolve them of blame for their countries' failure to advance. — John McCarthy
-
Faré -
Nathan Froyd -
Robert Goldman