Should I expect the *ASDF-REVISION* variable to work for me? Right now it's NIL. Is the definition of *ASDF-REVISION* a holdover from the CVS days, and no longer working, or is this YA case where there's something about git that I'm missing? Should I be doing something with the git pull that will get me a tags directory?
thanks, r
Hi Robert,
On Sep 6, 2009, at 11:13 PM, Robert Goldman wrote:
Should I expect the *ASDF-REVISION* variable to work for me? Right now it's NIL. Is the definition of *ASDF-REVISION* a holdover from the CVS days, and no longer working, or is this YA case where there's something about git that I'm missing? Should I be doing something with the git pull that will get me a tags directory?
*asdf-revision* both works and doesn't work. The mechanism I found to fill in git related metavariables was `git archive`. This only files stuff in on the tarball and the linked version of asdf.lisp. The variables in the git repo that you get by cloning/pulling don't have the magic variables converted and so so *asdf-revision* isn't much help. In practice, this means that people who get ASDF via git directly don't get the revision number whereas people who get ASDF via the tarball or the source file do.
If there is a better way, I'm all eyes.
(this sounds rather gross, but maybe a post pull hook could grab that latest tag out of the repo and munge that into the source... ?) -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
Gary King wrote:
Hi Robert,
On Sep 6, 2009, at 11:13 PM, Robert Goldman wrote:
Should I expect the *ASDF-REVISION* variable to work for me? Right now it's NIL. Is the definition of *ASDF-REVISION* a holdover from the CVS days, and no longer working, or is this YA case where there's something about git that I'm missing? Should I be doing something with the git pull that will get me a tags directory?
*asdf-revision* both works and doesn't work. The mechanism I found to fill in git related metavariables was `git archive`. This only files stuff in on the tarball and the linked version of asdf.lisp. The variables in the git repo that you get by cloning/pulling don't have the magic variables converted and so so *asdf-revision* isn't much help. In practice, this means that people who get ASDF via git directly don't get the revision number whereas people who get ASDF via the tarball or the source file do.
If there is a better way, I'm all eyes.
(this sounds rather gross, but maybe a post pull hook could grab that latest tag out of the repo and munge that into the source... ?)
Is there something I might not be doing (or we might not be doing as a community) that makes this not work? I have been pulling from your repository, but I don't *believe* that I have your tags (or do I)?
When I try `git describe --tags` I get no joy...
Is there any chance that you are not pushing your tags to the repository?
From a basis of complete ignorance, I have found the following:
http://www.question-defense.com/2009/03/13/software-revision-numbers-with-gi...
Which seems to indicate that you must do something beyond a normal push to get the tags into the shared repository. Are you doing this? If not, would you mind trying it?
I believe that if we were to get your tags into our clones of your repository, we could figure out a way to get the *ASDF-REVISION* set properly.
I note that the official stance seems to be that keyword substitution is "just totally idiotic" [Torvalds], http://www.gelato.unsw.edu.au/archives/git/0610/28891.html but that said I'm not sure how to replace it with something better. I'd like to be able to run ASDF from the git repository, and I'd also like to be able to do something like VERSION-SATISFIES based on the *ASDF-REVISION*.
Any reason why we shouldn't just butcher a version number string into the file when we release it, instead of doing the current rigamarole? Or is there a git wizard, who can supply a better alternative?
Hi Robert,
I didn't know about --tags; please try now and see what shakes out.
We should think more about
http://www.question-defense.com/2009/03/13/software-revision-numbers-with-gi...
This, by the way, was my birthday and therefore some sort of sign of the cosmic unconscious.
I believe that if we were to get your tags into our clones of your repository, we could figure out a way to get the *ASDF-REVISION* set properly.
Yes.
Any reason why we shouldn't just butcher a version number string into the file when we release it, instead of doing the current rigamarole? Or is there a git wizard, who can supply a better alternative?
Well, the tag is in the _released_ file; just not in the repo; that'll be the next step.
thanks again, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
Gary King wrote:
Hi Robert,
I didn't know about --tags; please try now and see what shakes out.
That seems to have fixed it:
[rpgoldman-2:~/lisp/asdf] rpg% git describe --tags 1.362-2-g07f9837
We should think more about
http://www.question-defense.com/2009/03/13/software-revision-numbers-with-gi...
This, by the way, was my birthday and therefore some sort of sign of the cosmic unconscious.
I believe that if we were to get your tags into our clones of your repository, we could figure out a way to get the *ASDF-REVISION* set properly.
Yes.
Any reason why we shouldn't just butcher a version number string into the file when we release it, instead of doing the current rigamarole? Or is there a git wizard, who can supply a better alternative?
Well, the tag is in the _released_ file; just not in the repo; that'll be the next step.
I have been pondering this, admittedly from the point of view of someone who is git-illiterate (ilgiterate?), and the more I think about it, the more I like this solution:
(defvar *asdf-revision* "1.362")
This has the immense advantage of simplicity going for it. The alternatives that I gather from reading Linus, et al. all seem ill-suited for the CL world. They seem to rely on (1) source to source textual translation /outside/ the lisp environment (e.g., Linus proposes to push the version number from git tags into into the Makefile) and (2) easy access to the standard unix toolchain (make, perl, git). But access to the unix toolchain, portably, from CL is not a nice thing, and it doesn't come cheap. Worse, getting this right relies on some tricky logic to detect the fact that you're running from a git working directory (so you haven't had textual substitution performed during the export process), and so need to take an excursion through git-describe.
I'm OK with coming up with an elegant solution that fixes this automagically using git tagging, git describe and so on, but until the messiah comes, how about we do the dumb thing and just stick in a string constant?*
"Il meglio, e l'inimico del bene" [the best is the enemy of the good] --- Voltaire
*If you want, you could make a shell script that wraps around the git tag command, incrementing the release number, pushing the release number into the *asdf-revision* defvar, committing the change, and then applying the tag. That would be pretty much automatic, but the logic wouldn't have to be replicated everywhere that asdf is loaded.
Uh? Whoever uses git to access asdf source code ipso facto has access to a chunk of non-trivial unix software, and can be assumed to be able to run a script. For instance, one that appends (SETF ASDF::*REVISION* "1.362-2-g07f9837") to asdf.lisp before it is copied over to its installation path, or otherwise updates the defvar line.
Whoever uses an installed ASDF will thus have a version number.
And if you're using directly it from git rather than from an installed version, youre responsible for what you're using, and you can trivially ensure that the version you're using is no ealier than whatever version you need. [Ensuring that there are no regressions is slightly harder; you might want to invest in some version-pinning technology for reproducible deployments.]
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Gilb's Law: Anything you need to quantify can be measured in some way that is superior to not measuring at all.
2009/9/8 Robert Goldman rpgoldman@sift.info:
Gary King wrote:
Hi Robert,
I didn't know about --tags; please try now and see what shakes out.
That seems to have fixed it:
[rpgoldman-2:~/lisp/asdf] rpg% git describe --tags 1.362-2-g07f9837
We should think more about
http://www.question-defense.com/2009/03/13/software-revision-numbers-with-gi...
This, by the way, was my birthday and therefore some sort of sign of the cosmic unconscious.
I believe that if we were to get your tags into our clones of your repository, we could figure out a way to get the *ASDF-REVISION* set properly.
Yes.
Any reason why we shouldn't just butcher a version number string into the file when we release it, instead of doing the current rigamarole? Or is there a git wizard, who can supply a better alternative?
Well, the tag is in the _released_ file; just not in the repo; that'll be the next step.
I have been pondering this, admittedly from the point of view of someone who is git-illiterate (ilgiterate?), and the more I think about it, the more I like this solution:
(defvar *asdf-revision* "1.362")
This has the immense advantage of simplicity going for it. The alternatives that I gather from reading Linus, et al. all seem ill-suited for the CL world. They seem to rely on (1) source to source textual translation /outside/ the lisp environment (e.g., Linus proposes to push the version number from git tags into into the Makefile) and (2) easy access to the standard unix toolchain (make, perl, git). But access to the unix toolchain, portably, from CL is not a nice thing, and it doesn't come cheap. Worse, getting this right relies on some tricky logic to detect the fact that you're running from a git working directory (so you haven't had textual substitution performed during the export process), and so need to take an excursion through git-describe.
I'm OK with coming up with an elegant solution that fixes this automagically using git tagging, git describe and so on, but until the messiah comes, how about we do the dumb thing and just stick in a string constant?*
"Il meglio, e l'inimico del bene" [the best is the enemy of the good] --- Voltaire
*If you want, you could make a shell script that wraps around the git tag command, incrementing the release number, pushing the release number into the *asdf-revision* defvar, committing the change, and then applying the tag. That would be pretty much automatic, but the logic wouldn't have to be replicated everywhere that asdf is loaded.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On somewhat more mature consideration, I believe that this problem, to the extent it is a problem, simply comes from misplacing the operation of inserting the revision number into the file. Currently, the operation is done at the point of exporting asdf.lisp into a tarball. In my previous email (unfortunately only in a footnote), I proposed a technique for moving the revision insertion from export to tag application. I believe that if the makefile (or some shell script) is modified in the way I propose, everyone should be happy.
This modification would make no additional work for Gary, and would lift the burden of massaging the source file from everyone running ASDF from a git checkout. It would have the added benefit of removing 16 lines of lisp source that do fussy string manipulations to set *asdf-revision*. This seems like a good trade-off --- a few lines of shell script or makefile provides an easy operation for Gary (and simplifies the export), and saves work for the development community.
Would this be an acceptable solution?
This modification would make no additional work for Gary, and would lift the burden of massaging the source file from everyone running ASDF from a git checkout. It would have the added benefit of removing 16 lines of lisp source that do fussy string manipulations to set *asdf-revision*. This seems like a good trade-off --- a few lines of shell script or makefile provides an easy operation for Gary (and simplifies the export), and saves work for the development community.
Hi Robert,
I think so; besides, I'd love to get rid of that "fussy string manipulation" code (which is a great description of it, though futzy would be equally apt). -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
-
Faré -
Gary King -
Robert Goldman