Wow, now that <http://wiki.sagemath.org/SPKG_Audit> just had been updated considerably during the last days (I was unsuccessfully chasing a moving target there), it seems we can at least double again the information about how to create a spkg (and about how *certainly not* to do it).
Michael, I do thank you for, and I thoroughly appreciate your precise and concrete criticism! Admittedly, I already knew a few of the points, but you also brought up some new arguments I never would have thought of. The one hurting most deeply is about "Keep It Stupid Simple" --- yep, in its current shape this spkg plainly isn't simple. Martin, thanks for your support! Allow me to point out some goodies, before going through the not-so- goodies: * infrastructure to cleanly remove an installed spkg from a Sage install, i.e. the spkg-remove script and most importantly the "one- click" extlibs-nukeall script: These were introduced exactly with "bdist" in my mind, and to be able to deal with "random repos in Sage's devel". If you object to "$SAGE_ROOT/devel" as a place in the directory tree --- where else to put it? Extcode? Or maybe Examples? I thought to have found the least bad place. (And it just can't be moved entirely "out" of the Sage tree, think of "local/lib", "local/include", ".../site-packages/...") * Modularized "module_list.py", there's one of them in each subdirectory with Cython source code: Even for the "monolithic" module_list.py of the Sage core, the current Python/Cython distutils/setuptools simply do not offer the functionality we need. This might change in the future, but for now, one e.g. has to copy over the ".pyx" files with "non-generic" command infrastructure to site-packages/. And telling distutils, which extra C sources, libraries, macro definitions and command line options to take into account, is still quite some problem (think of the ".spyx pragmas"). Having the "module_list.py" data in the very directory where the Cython source code resides, does at least keep those things close together that do "belong" together. And now for the not-so-goodies: * "At the very top-level": If I would have to redesign the whole thing from scratch, given your input and my knowledge up to right now, I would go for three different (but intimately related) spkg packages: First spkg: The "pure" C Library Second spkg: The Cython Wrapper code (going ultimately into "site- packages" side-to-side to the sage core code) Third spkg: The "Extlibs" infrastructure / scripts (hopefully some day obsoleted by becoming part of Sage itself) I'm curious whether one is able to do the "second" spkg using setuptools/distutils only. This would come as a surprise to me, see my thoughts about "module_list.py" above. * "Every file in src is in the repo --- don't do that": OK, I won't do it again * "This is not KISS": Breaking things down is easier than building things up, and "KISS" is a valid goal -- I'm working on it * "spkg-install too big": That's because of the infrastructure for the "removal of a spkg", and can easily be outsourced * "patches dir abusal": The clean way is to move the "extlibs" scripts to their own spkg. * "No need to add other repos back": I disagree. Personally, I have a hen-and-egg problem, and need a solution in this very direction. More precisely, I have some C code (that is not getting younger) of mine that ultimately, I would like very much to see incorporated in Sage. However, there is still quite some development work to be done on it. The Sage infrastructure does allow me to do this outstanding development work so much faster and better. Most probably, I simply couldn't get to finish my work without it. OTOH, in its current shape, my code certainly is not ready even for a preliminary review (A part of it is on the Web site for that Bristol conference this year, by the way). So what is to come first - the hen, or the egg? Maybe I am the only person on this planet having this problem, but I have the feeling that there are others who could profit from that "repo framework". Think of it as temporary crutch, helping more and more code to mature, and to get into Sage. * "SPKG.txt" What is wrong about "(see also hg log)"? I did rewrite SPKG.txt several times to get it right and thought to have put all information needed in it (it does say it requires "a standard Sage install", which includes Cython). Before we all get even more frustrated, let's post three or four real-life and "absolutely positively correct" sample SPKG.txt files in the Wiki. * "Go improve the documentation": I wanted to do that anyway, but get out the exampleclib spkg first. It contains a Readme file for every directory in the spkg, and a line or two out of these will suddenly find itself being part of a trac ticket patch for some Sage doc. * William wrote much code that I just copied (e.g. in the build scripts), he started and invented the Sage infrastructure. And there has been (I think it's deleted now) somewhere in the documentation the request to add him to the Copyright holders. I expect William to answer this question himself, and then do as he tells me. * "Technically the following is more elegant, but we don't do it yet (Second message from Michael) ...": Good point! I have to think about it. Cheers, gsw --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
