[asdf-devel] Should ASDF define many packages?
sds filed an interesting bug: https://bugs.launchpad.net/bugs/620579 The question is whether we should avoid creating extra packages, and instead export all relevant functions from ASDF, or should we keep those separate packages ASDF-BOOTSTRAP and ASDF-UTILITIES. Does anyone of you use functions from ASDF-UTILITIES? Does any of you :use ASDF-UTILITIES? Should I just export the same functions from ASDF instead? Would you see a problem with ASDF-UTILITIES either disappearing or becoming an alias for ASDF? PS: we're at ASDF 2.005 (=2.120), and considering the sudden surge of bugs that led to 2.121, there will be a 2.006 soon. Sigh. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [A] Computer [programming] language is inherently a pun — [it] needs to be interpreted by both men & machines. — hbaker
On Thu, Aug 19, 2010 at 9:04 PM, Faré <fahree@gmail.com> wrote:
The question is whether we should avoid creating extra packages, and instead export all relevant functions from ASDF, or should we keep those separate packages ASDF-BOOTSTRAP and ASDF-UTILITIES.
I think the too-many-packages problem is not worth wasting time. I would rather be interested on a _simpler_ bootstrapping process, which can be used by implementations shipping ASDF. I mean, given that ASDF is not loaded, being able to skip all the code related to clever renaming of packages, interning / uninterning symbols, etc.
Does anyone of you use functions from ASDF-UTILITIES? Does any of you :use ASDF-UTILITIES?
Not that I am aware of.
PS: we're at ASDF 2.005 (=2.120), and considering the sudden surge of bugs that led to 2.121, there will be a 2.006 soon. Sigh.
On reading your replies to the bug report, I appreciate you do not find it essential that implementations ship the latest version of ASDF, or that at least users should not rely on it. Nevertheless, I believe it would be interesting to rescue the idea of issuing periodic announcements of milestone releases that implementations should include. Not as verbose as the ASDF2 letter, but at least one email pointing out: hey, include this. Alternatively, I would contemplate the possibility of including a configuration step in ECL that downloads the latest ASDF. That would be easy, just looking for the existence of internet connection + wget/curl, but we would need a stable and permanent address for ASDF files to be downloaded. I mean individual files, not really a tarball. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
On 20 August 2010 04:32, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com> wrote:
On Thu, Aug 19, 2010 at 9:04 PM, Faré <fahree@gmail.com> wrote: I think the too-many-packages problem is not worth wasting time. I would rather be interested on a _simpler_ bootstrapping process, which can be used by implementations shipping ASDF. I mean, given that ASDF is not loaded, being able to skip all the code related to clever renaming of packages, interning / uninterning symbols, etc.
I merged all the packages back into ASDF. Some consider it a good thing, some consider it a bad thing. I don't care anymore; if someone does care, he better accept maintainership of that part of the code. This merge did simplify this somewhat. But the code already was and remains "clever" in not doing any unnecessary uninterning.
On reading your replies to the bug report, I appreciate you do not find it essential that implementations ship the latest version of ASDF, or that at least users should not rely on it.
Yes, that was essential to our ASDF 2 strategy. That doesn't mean we don't recommend implementors to ship with the latest. We *do* beg vendors to always ship with the latest; at the very least to ship with *some* version of ASDF 2. But we don't rely on it.
Nevertheless, I believe it would be interesting to rescue the idea of issuing periodic announcements of milestone releases that implementations should include. Not as verbose as the ASDF2 letter, but at least one email pointing out: hey, include this.
Once in a while, I try to send something to each implementation's mailing-list. I get precious little replies (and none at all from commercial vendors, except for SCL and long ago a now-expired Lispworks test license).
Alternatively, I would contemplate the possibility of including a configuration step in ECL that downloads the latest ASDF. That would be easy, just looking for the existence of internet connection + wget/curl, but we would need a stable and permanent address for ASDF files to be downloaded. I mean individual files, not really a tarball.
I wrote a script to do just that in sbcl's contrib/asdf. They didn't get my latest version, but here's the Makefile target, that you can tailor to your needs: up: if [ -d asdf-upstream ] ; then \ cd asdf-upstream ; git checkout release ; git reset --hard release ; git pull -a ; else \ git clone --branch release \ git://common-lisp.net/projects/asdf/asdf.git asdf-upstream ; fi cp asdf-upstream/asdf.lisp asdf.lisp cp asdf-upstream/doc/asdf.texinfo asdf.texinfo cp asdf-upstream/README README cd asdf-upstream ; make archive cp asdf-upstream/LICENSE LICENSE Thanks a lot for your support! PS: still no ECL support in XCVB. Sorry. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] First they ignore you. Then they laugh at you. Then they fight you. Then you win. — Gandhi
On Tue, Aug 31, 2010 at 9:12 PM, Faré <fahree@gmail.com> wrote:
Alternatively, I would contemplate the possibility of including a configuration step in ECL that downloads the latest ASDF. That would be easy, just looking for the existence of internet connection + wget/curl, but we would need a stable and permanent address for ASDF files to be downloaded. I mean individual files, not really a tarball.
I wrote a script to do just that in sbcl's contrib/asdf. They didn't get my latest version, but here's the Makefile target, that you can tailor to your needs:
up: if [ -d asdf-upstream ] ; then \ cd asdf-upstream ; git checkout release ; git reset --hard release ; git pull -a ; else \ git clone --branch release \ git://common-lisp.net/projects/asdf/asdf.git asdf-upstream ; fi
Do you realize that "git" is not a suitable distribution method for many users? It would be more interesting to have a permanent web address for the latest stable release, from which to download it -- a process that can then be performed in many other ways. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
On 8/31/10 Aug 31 -2:47 PM, Juan Jose Garcia-Ripoll wrote:
Do you realize that "git" is not a suitable distribution method for many users? It would be more interesting to have a permanent web address for the latest stable release, from which to download it -- a process that can then be performed in many other ways.
Is the tarball on the common-lisp.net site not a solution to this problem?
On 19 August 2010 22:04, Faré <fahree@gmail.com> wrote:
The question is whether we should avoid creating extra packages, and instead export all relevant functions from ASDF, or should we keep
Exporting random internal utilities from ASDF is a terrible idea, IMO. People will use them, and then you will be oblidged to maintain them even when you decide that they're not what you wanted. They also pointlessly pollute the namespaces of clients who use ASDF. (It doesn't personally bother me, but it just seems wrong on pretty much every level.) Cheers, -- Nikodemus
On 31 August 2010 12:55, Nikodemus Siivola <nikodemus@random-state.net> wrote:
On 19 August 2010 22:04, Faré <fahree@gmail.com> wrote:
Exporting random internal utilities from ASDF is a terrible idea, IMO.
The utilities are not completely random. I use them, and other people use them.
People will use them, and then you will be oblidged to maintain them even when you decide that they're not what you wanted.
That's the whole point. I want to be able to (require :asdf) and then use (asdf:getenv ...) to configure things. Not have to reinvent merge-pathnames* or pathname-directory-pathname or split-string or truenamize. As for aif and appendf they were singled out before my time and I don't think there's anything wrong with them. Should I stop exporting them? Possibly. But why? I don't have a strong opinion.
They also pointlessly pollute the namespaces of clients who use ASDF.
One man's "pollution" is another man's "great stuff". In any case, just as for any other package, if you (:use :ASDF) instead of using ASDF:... prefixed symbols or (:import-from :ASDF ...) them one by one, you accept that you'll get whichever symbols ASDF will export in the future. You get what you ask for, and ASDF will not stop changing just because of you.
(It doesn't personally bother me, but it just seems wrong on pretty much every level.)
I agree that namespace management in CL is wrong on pretty much every level. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If the human mind were simple enough to understand, we'd be too simple to understand it. — Pat Bahn
On 8/31/10 Aug 31 -2:03 PM, Faré wrote:
On 31 August 2010 12:55, Nikodemus Siivola <nikodemus@random-state.net> wrote:
On 19 August 2010 22:04, Faré <fahree@gmail.com> wrote:
Exporting random internal utilities from ASDF is a terrible idea, IMO.
The utilities are not completely random. I use them, and other people use them.
People will use them, and then you will be oblidged to maintain them even when you decide that they're not what you wanted.
That's the whole point. I want to be able to (require :asdf) and then use (asdf:getenv ...) to configure things. Not have to reinvent merge-pathnames* or pathname-directory-pathname or split-string or truenamize. As for aif and appendf they were singled out before my time and I don't think there's anything wrong with them. Should I stop exporting them? Possibly. But why? I don't have a strong opinion.
They also pointlessly pollute the namespaces of clients who use ASDF.
One man's "pollution" is another man's "great stuff".
In any case, just as for any other package, if you (:use :ASDF) instead of using ASDF:... prefixed symbols or (:import-from :ASDF ...) them one by one, you accept that you'll get whichever symbols ASDF will export in the future. You get what you ask for, and ASDF will not stop changing just because of you.
(It doesn't personally bother me, but it just seems wrong on pretty much every level.)
I agree that namespace management in CL is wrong on pretty much every level.
I'd just like to amplify Faré's response in one way. The internal utilities are really not random. One of the things discovered in the course of building ASDF 2 (and cemented, for me, in the process of writing an ILC paper about it with Faré) is the complete inadequacy of CL pathnames for portable operations. Pathname-wrangling is very likely something that an ASDF system definer --- and even more an ASDF system extender --- will need to deal with. So functions to operate on them are a critical tool that ASDF must supply. Indeed, file and directory access in general is not adequately supported in a portable way. Similarly, in order to make it possible for ASDF extenders to process new types of components, we need a portable version of something like RUN-SHELL-COMMAND, and this cannot be supplied /to/ ASDF, it must be supplied /by/ ASDF. Now, arguably people who are simply going to define simple ASDF systems should have a simple API, which means a package that exports only the minimum necessary set of symbols. This would have to be complemented by a "fatter" API. However, this correspondence started with an objection to defining multiple packages/multiple APIs. The necessary consequence of this objection is that there will be a single, fat API, and more, rather than less, namespace pollution. [For the record, I would have preferred a thinner set of ASDF exports, accompanied by a utilities package or set of packages.] Finally, because of how central ASDF is to the CL community, I don't believe that we should repair previous namespace pollution. If something has in the past been exported from ASDF, it should almost certainly continue to be exported, even if it's something like APPENDF or AIF, that is pretty clearly inappropriate. That namespace pollution has already happened, and breaking existing systems to fix it would be inappropriate. Best, r
On 31 August 2010 22:03, Faré <fahree@gmail.com> wrote:
On 31 August 2010 12:55, Nikodemus Siivola <nikodemus@random-state.net> wrote:
Exporting random internal utilities from ASDF is a terrible idea, IMO.
The utilities are not completely random. I use them, and other people use them.
The word was ill-chosen. What I ment was that they appear to have very little with the rest of ASDF looking from outside in. Robert's point regarding lack of portable pathname wrangling tools is also well made. Looking at the export list the following are the ones that "look random" to me -- having little obvious relation to res of ASDF: #:aif #:appendf #:coerce-name #:ends-with #:length=n-p #:read-file-forms #:remove-keys #:remove-keyword #:split-string #:while-collecting Then again, it is certainly a reasonable to say that you don't export anyone to :use ASDF in a general purpose package, that only ASDF extensions and system definition files should do that -- and that since depending on external utility packages is nasty for those, ASDF comes with a some extra goodies. *shrug* Cheers, -- Nikodemus
On 8/31/10 Aug 31 -3:33 PM, Nikodemus Siivola wrote:
On 31 August 2010 22:03, Faré <fahree@gmail.com> wrote:
On 31 August 2010 12:55, Nikodemus Siivola <nikodemus@random-state.net> wrote:
Exporting random internal utilities from ASDF is a terrible idea, IMO.
The utilities are not completely random. I use them, and other people use them.
The word was ill-chosen. What I ment was that they appear to have very little with the rest of ASDF looking from outside in.
Robert's point regarding lack of portable pathname wrangling tools is also well made.
Looking at the export list the following are the ones that "look random" to me -- having little obvious relation to res of ASDF:
#:aif #:appendf #:coerce-name #:ends-with #:length=n-p #:read-file-forms #:remove-keys #:remove-keyword #:split-string #:while-collecting
Of these, I would say that COERCE-NAME, SPLIT-STRING, and probably READ-FILE-FORMS are actually not random. COERCE-NAME is something like SYMBOL-NAME for ASDF: SYMBOL-NAME is /not/ how you want to look up an ASDF system. SPLIT-STRING is used for filename wrangling. READ-FILE-FORMS is used to wrangle configuration files. It's a borderline case. The others seem more like programming utilities that could be dispensed with. I think we're probably stuck with AIF and APPENDF, but WHILE-COLLECTING and some of the others might be safely dispensable. cheers, r
On 31 August 2010 16:39, Robert Goldman <rpgoldman@sift.info> wrote:
#:aif #:appendf #:ends-with #:length=n-p #:remove-keys #:remove-keyword I removed these from the export list in 2.126. Does this require an urgent 2.008 release? (Indeed, exporting aif without exporting it is pointless. The original export list wasn't fully thought out.)
#:coerce-name #:read-file-forms #:split-string #:while-collecting coerce-name is part of the protocol. So is split-string, to a lesser point. And it is actually used by clients. read-file-forms and while-collecting are a bit mooter, though they are very useful to define extensions to existing protocol in the same style as ASDF.
The others seem more like programming utilities that could be dispensed with. I think we're probably stuck with AIF and APPENDF, but WHILE-COLLECTING and some of the others might be safely dispensable.
I removed AIF and APPENDF, because they are both more likely to cause clashes, and not specific enough to help ASDF clients partake in an "ASDF style". Hopefully, no one was using them from the ASDF package. Or they can use :: [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The risk is that if, one day, machines become intelligent, we mightn't be mentally equipped to notice they are. — Tirésias, in J.-P. Petit, "A quoi rêvent les robots?"
participants (4)
-
Faré -
Juan Jose Garcia-Ripoll -
Nikodemus Siivola -
Robert Goldman