On Dec 23, 1:31 pm, "Georg S. Weber" <georgswe...@googlemail.com>
wrote:
Hi Georg,
> 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).
Well, that wasn't really new, if was just not documented in the wiki.
If you look at spkgs reviews in trac the same issues have popped up
over and over again. :)
> 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:
What do you mean by that? spkg removal is at best a dangerous and
inexact fashion. There has been some discussion about doing something
clever for optional and experimental spkgs, but nobody ever submitted
any code for review. I am talking about sticking optional things into
a per spkg tree so that removal would be trivial by nuking that tree
only.
> 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/...")
I don't think there should be any of those repos at all. If you are
working on an external project there is no point in keeping it in
devel. If your code depends on Sage infrastructure you are likely
doing something wrong, i.e. your modular forms C/C++ code should be in
one spkg as library code and then you should create a branch to work
on bindings or alternatively go the site-packages only route for now
and once the code has improved/matured move it into the Sage library.
> * Modularized "module_list.py", there's one of them in each
> subdirectory with Cython source code:
I didn't say that at all.
> 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/.
That is because we are (ab)using distutils in a non-standard way. Any
"proper" Python/Cython project can use distutils out of the box.
> 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").
Why? Invoke setup.py with the right env parameters from spkg-install.
> 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.
I disagree or at least I do not get your point and this is just a
misunderstanding. I never advocated to share module_list.py with any
external code, just to use analog infrastructure.
> 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
This just need to be documented, i.e. the example needs to be moved
from the wiki into the "official" documentation. There are dozens of
examples in the tree that can be copied, but keep it really simple. I
don't even see the need to provide an actual example since the
documentation should contain all the needed bits so that it can be
copy and pasted.
> Second spkg: The Cython Wrapper code (going ultimately into "site-
> packages" side-to-side to the sage core code)
Well, the Cython.spkg and many others already show how that is done.
This is also a documentation problem.
> 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.
I don't think we need this at all. As I mentioned above I see no
reason to support this since external code should be developed
externally.
> * "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
Well, I don't think we need the removal option, but I am repeating
myself :)
> * "patches dir abusal": The clean way is to move the "extlibs" scripts
> to their own spkg.
I don't think we need those. And if those would be accepted the right
place is the sage scripts repo since this is common infrastructure.
> * "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.
Just use your favorite version control system and have some kind of
target that builds the needed bits and copies them into the Sage tree.
That is why I always tell people to use hg directly and not the Sage
wrappers since one needs to learn how to use the tool directly sooner
or later anyway. Sage IMHO is not meant to be a hosting environment to
develop library code outside the Sage library.
> * "SPKG.txt" What is wrong about "(see also hg log)"?
Top level changes *must* be documented in SPKG.txt. Some people wanted
to deprecate SPKG.txt since all the changes were in the hg repo
anyway. If you have ever looked for what happened a couple releases
back by looking at the hg repo when huge files were added/removed due
to upstreaming you will see my point.
> 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.
See http://wiki.sagemath.org/Sage_Spkg_Tracking for a list of
hopefully decent SPKG.txt examples. A template can be found at
http://wiki.sagemath.org/spkgTemplate - the template is not 100% the
way I want it yet, but it is a decent start.
> * "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.
I don't think any documentation should go in some README.txt beyond a
simple README.txt in the root of the spkg that states: "This is an
example spkg. For documentation please see $URL". I much prefer for
documentation to be in one place and it isn't in tree in some SPKG
somewhere.
> * 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.
Sure, but if you write a new script why would you share copyright with
him? I don't care, I just have seen people do it and it strikes me as
plain wrong.
> * "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.
Please, if you work on this keep things *really* simple, i.e. not much
beyond a "Hello World" as a library, Cython or whatever example. If
the example is larger than 3 kb compressed you are doing something
wrong.
> Cheers,
> gsw
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
