> > Fantastic! The naming convention for spkgs that includes the .pn > > post-fix where n labels the spkg version is probably not needed now. > > My understanding is that label was loosely used as a sort of version > > control. I think simply having the hg repo for each solves that > > problem. Also, there doesn't seem to be any real consistent approach > > for updating those numbers. My though would be to get rid of them. > > Then SAGE wouldn't know that the package had been updated. > Those version numbers are used to determine whether it is > necessary to install a package.
I didn't know SAGE was actually using them. Is this when sage -update is run? My understanding is that the decision to upgrade something was based on the timestamps if the files compared with the stub in the installed directory. Am I mistaken. Is there a standard approach for these version numbers? At times I have seen a projects version number upgraded, but the .pn version number remain the same. For instance, the python spkg is named: python-2.5.1.p3.spkg But I don't think the .p3 means the third version of the spkg for python-2.5.1. This seems a bit confusing to me. Especially because some spkgs don't have a .pn version, even though they were updated. I don't mind having a version that denotes the spkg version, I just want to make sure that those version number are consistent and standardized and have a purpose that is not redundant. Could we use md5 sums for this? In many cases, I do this anyway, because the .pn version number is not a reliable way of determining if an spkg has changed. > > The other thing that I am not sure how to handle (part of this is my > > lack of experience with hg) is the names of the directories > > themselves, for example: > > > > freetype-2.1.10.spkg > > > > When freetype gets upgraded to 2.1.11, do we simply rename the > > directory to freetype-2.1.11? Will hg be happy with that? Sorry, I > > just don't know how hg treats directory renames. > > With hg it's just that there is a directory .hg instead freetype-2.1.10. > Hg has no idea what the directory is called that it is in, and it doesn't > care. > > We will need an easy SAGE tool to merge two versions of a package, > e.g., to pull from a latest published version of the package, to take > to freetype-* packages, say that I and didier made, and -- with > almost no work -- merge them into a single new package. This can > easily be automated, by calling "hg pull", then using "sage -pkg". > > > > One note: I would prefer that READMET.txt be kept as SAGE.txt (or > > > renamed to something else) because then it would be clear that > > > modifications were made to the spkg. I tend to ignore README.txt's > > > anyway because they don't tell you why you should read them. > > > > I agree that README.txt is a little confusion, but because the spkgs > > are being used outside of SAGE, I would name the file something that > > emphasizes that it is really the readme for the spkg: > > > > SPKG.txt > > SPKG-README.txt > > > > or something like that. > > One issue is that it isn't a readme, actually. It's a description of how > the package was made. True, then maybe SPKG.txt makes more sense? Or maybe BUILD-NOTES.txt? SPKG-BUILD-NOTES.txt? > > One of the things I have been working on (on > > my private copies) is to decouple the spkg build system from the > > details of sage itself. This has mostly meant changing the name > > "sage" to "spkg" in the context of the build system. > > > > > > > On 6/1/07, Brian Granger <[EMAIL PROTECTED]> wrote: > > > > 2. The other scripts/makefiles involved in the spkg build process - > > > > like newest_version, install, save-env, etc. > > > > > > sage-env is under version control, but the others aren't. > > > > > > > > > > 3. The overall directory structure that contains the > > > > scrips/makefiles. The reason this is important is that most of the > > > > scripts make strong assumptions about where they are run from. Also, > > > > as I have begun refactoring, some of the scripts have been moved > > > > around (for instance newest_version has been moved to > > > > base/spkg-newest-version). Managing this without the associated > > > > directory structure is a pain. > > > > > > Are you talking about the scripts in SAGE_ROOT/local/bin ? Because > > > they are under version control (this is where sage-env lives too). > > > > I am talking about the both the directory structure that is needed for > > the script/makefiles to function properly: > > > > spkg/ > > standard/ > > base/ > > > > As well as the actual scripts and makefiles (deps, install, > > newest-version, etc) that have to be in particular locations in that > > tree to work properly. For instance, deps as to be in standard, > > install in spkg newest-version in standard, and a bunch of stuff has > > to be in base. > > > > Once the overall structure of these new spkgs have settled down, I > > will start to convert my private spkgs (I have things like (qt and > > pyqt4, and a bunch of other things) into this form. Then contributing > > them will be really simple. > > William > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
