On Oct 28, 2:15 am, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> 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.

-1 on the rename, too. It will cause massive problems without any
serious benefit whatsoever. The manual clearly describes what an spkg
is and provides tools to create them and so on. If one wants to play
with the innards of Sage and one is stopped by the fact that one does
not know what an spkg is (and also does not know about "file") one
also does not know about the structure inside an spkg which is much
more critical.

To add to William's list: rpms for example are also archives with a
certain structure and I don't see the rpm folks rename their extension
because it could be less confusing :)

> 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.

The info is already in the manual.

> - Robert

One could potentially allow tar.bz2 or .tar names spkgs by checking
for their existence when one does

 sage -i foo

but this is potentially laced with ambiguity (which one do I pick if
they both exist: foo.spkg, foo.tar or foo.tar.bz2).

Cheers,

Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to