[asdf-devel] About some new system slots
Hello, what's the purpose of the LONG-NAME slot in ASDF 3's system class? Also, can I assume that HOMEPAGE, SOURCE-CONTROL and BUG-TRACKER are meant to be URL strings ? Thanks. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
On Fri, Jul 5, 2013 at 5:55 AM, Didier Verna <didier@lrde.epita.fr> wrote:
what's the purpose of the LONG-NAME slot in ASDF 3's system class? (defsystem :asdf/defsystem :long-name "Another System Definition Facility" The system name might be an acronym — this would be its expansion.
Also, can I assume that HOMEPAGE, SOURCE-CONTROL and BUG-TRACKER are meant to be URL strings ? Yes, though this isn't enforced at the time.
Although, it isn't clear yet how source-control may or may not specify the VCS used: should we prefix the URL with a git: or svn: or darcs: or some such? ASDF uses: :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git") —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org He who refuses to do arithmetic is doomed to talk nonsense. — John McCarthy, in his webpage on Progress and Sustainability
Faré <fahree@gmail.com> wrote:
Although, it isn't clear yet how source-control may or may not specify the VCS used: should we prefix the URL with a git: or svn: or darcs: or some such? ASDF uses: :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git")
Personally, I would not complicate this slot and just go for a simple URL pointing to a VCS related web page. If you start specifying more information there, you will end up with a big mess (which VCS, which access backend, which access type (r/o r/w) etc.). That's just me of course. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Didier Verna wrote:
Faré <fahree@gmail.com> wrote:
Although, it isn't clear yet how source-control may or may not specify the VCS used: should we prefix the URL with a git: or svn: or darcs: or some such? ASDF uses: :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git")
Personally, I would not complicate this slot and just go for a simple URL pointing to a VCS related web page. If you start specifying more information there, you will end up with a big mess (which VCS, which access backend, which access type (r/o r/w) etc.).
That's just me of course.
The advantage of having the pair, of course, is that a simple URL does not necessarily identify the form of VCS. My preference would be to a. document a proposed format (e.g., Faré's two-element list of keyword + URL -- possibly keyword + ancillary info to permit some hypothetical VCS that does not use URLs); b. check this format when parsing DEFSYSTEM, issuing a STYLE-WARNING when the meta-data doesn't comply; c. hope people provide useful information here, but not worry about it. Cheers, r
Robert Goldman <rpgoldman@sift.info> wrote:
The advantage of having the pair, of course, is that a simple URL does not necessarily identify the form of VCS.
But what would be the use for this information? I mean, having this information as part of the system desciption. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Didier Verna wrote:
Faré <fahree@gmail.com> wrote:
Although, it isn't clear yet how source-control may or may not specify the VCS used: should we prefix the URL with a git: or svn: or darcs: or some such? ASDF uses: :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git")
Personally, I would not complicate this slot and just go for a simple URL pointing to a VCS related web page. If you start specifying more information there, you will end up with a big mess (which VCS, which access backend, which access type (r/o r/w) etc.).
That's just me of course.
I can think of two answers to this: 1. I believe that the value of a *human-readable* piece of meta-data here should be obvious. Particularly if you get a version of a library from some source (tarball, quicklisp), that has a bug you wish to fix. It would be nice if you didn't have to track down the VCS for yourself (particularly if there are multiple possible candidates in DVCS world). But for this all we need is an arbitrary string such as "git repository git://common-lisp.net/projects/asdf/asdf.git". This requires no action on the part of the ASDF developers. Note that Faré's format meets this criterion, as well. 2. It is an open question whether *machine-readable* meta-data would be useful. My previous response was directed at machine-readable meta-data. This could be either (a) something that prescribes enough of a format to ensure happily formatted information (e.g., for CL-TEST-GRID), or (b) something that would support automated access to the version control repository encoded in the system description. As I said, it's not clear that this is needed right now. My proposal would aim at this, but is probably premature.
On Mon, Jul 8, 2013 at 12:25 PM, Robert Goldman <rpgoldman@sift.info> wrote:
1. I believe that the value of a *human-readable* piece of meta-data here should be obvious. Particularly if you get a version of a library from some source (tarball, quicklisp), that has a bug you wish to fix. It would be nice if you didn't have to track down the VCS for yourself (particularly if there are multiple possible candidates in DVCS world). But for this all we need is an arbitrary string such as "git repository git://common-lisp.net/projects/asdf/asdf.git". This requires no action on the part of the ASDF developers. Note that Faré's format meets this criterion, as well.
Yes, and because darcs, svn, git, and possibly more, can all be done over http, it isn't sufficient to have a URL, and/or that would require some magic autodetection. Explicit specification of the VCS seems better to me.
2. It is an open question whether *machine-readable* meta-data would be useful. My previous response was directed at machine-readable meta-data. This could be either (a) something that prescribes enough of a format to ensure happily formatted information (e.g., for CL-TEST-GRID), or (b) something that would support automated access to the version control repository encoded in the system description. As I said, it's not clear that this is needed right now. My proposal would aim at this, but is probably premature.
At the very least, machine readable means you can automate the push-button task of downloading the upstream source of a system and/or all its relevant dependencies when given a tarball, or a lisp image where the system is loaded. Admittedly, if the system is already in quicklisp, quicklisp can possibly give you the answer already, so this might be redundant. On the other hands, systems need not be in quicklisp. In any case, this was one feature requested by users, that I find passably useful, and that had been done badly in non-standard ways in the past in various systems, so I at least introduced the slot and a proposed format for it, but pending an actual documented proposal, nothing is enforced about the value in this slot as of yet. Of course, I'm not the one to decide anymore. I'm just here to assist the new maintainer in understanding previous decisions. Good luck, Robert! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Everything is interesting if you go into it *deeply* enough. — Richard Feynman
participants (3)
-
Didier Verna -
Faré -
Robert Goldman