On Oct 28, 2008, at 12:45 AM, Georg S. Weber wrote: > Hi, > > often I'd like to "just have a quick look" into a spkg. > Then I copy it, rename it, tell Mac OS X that YES, I do want to rename > it, > and then I can open it with a mouse click, and change into the created > directory. > Finally I am able to scan the contents. > It would be nice to be quicker, and with keeping the hand on the mouse > all the time (I'm not a keyboarder).
BTW, you can choose an app to open all .spkg files with an expander via the "get info" dialog. Though I'm more of a keyboard person, I can double-click on an .spkg and it expands right there. > On the other hand, we already have the naming convention "p0", "p1", > "p2" ... to designate different Sage spkg's made from one and the same > upstream source package. > > So I'd like to propose to (re-)name e.g. "polybori-0.5rc.p5.spkg" > either > > polybori-0.5rc.spkg5.tar.bz2 > > resp. > > polybori-0.5rc.spkg5.tar > > depending on whether it is also compressed or only tar'ed. > > We would have "numpy-1.2.0.spkg0.tar.bz2", "ntl-5.4.2.spkg4.tar.bz2", > and e.g. "sage-3.2.alpha.spkg1.tar.bz2" instead of > "sage-3.2.alpha1.spkg", "sage-3.2.rc.spkg0.tar.bz2" instead of > "sage-3.2.rc0.spkg", and the like. > > This would address points (1) - (3) from Williams post; and there > would be a canonical scheme to designate different spkg's from one and > the same upstream source. > (And it would make perfect sense what the meaning of > "sage-3.1.3.spkg2.tar.bz2" is: the second hotfix to the sage-3.1.3 > production version which had to be done even after the "alpha" and > "rc" cycles. Without the need to bump the version to sage-3.1.4, say.) > > BTW the only "hard" requirements for the structure of a Sage spkg are > that there is a file "SPKG.txt" in the root directory of the package, > and that Sage is able to figure out how to install the package then. > The code does look for a file "spkg-install", but e.g. only a > "setup.py" is also absolutely fine (for the code, maybe not for > reviewers). > > Cheers, > gsw > > > P.S.: > The only problem in parsing and handling the spkg names I see right > now is something like "foo-4711.spkg815.tar.bz2", i.e. a version as > spkg which has more than only one digit. But this shouldn't be a real > problem, either. I'm -1 on this idea. I can't quite put my finger on why I have a strong reaction, but I think it's because "sage-3.2.alpha.spkg1.tar.bz2" is harder to (visually) parse, and also it's important to emphasize that an spkg *should* be more structured than just a folder with a bunch of source files thrown in. It also allows us to do more in the future if we need/want, and making them with sage -spkg gives a lot of informative information (and again, I could see it doing more in the future). A big, fat README.txt should be explanatory enough for anyone who wants to poke inside. - Robert --~--~---------~--~----~------------~-------~--~----~ 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://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
