Hi:

Playing around with the experimental 4ti2 package (which is not to be
confused with Marshall Hampton's very recent 4ti2 spkg) *and* Nathann
Cohen's GLPK spkg in the same version of Sage got me thinking about
some issues.

What is stopping people from (accidentally) causing havoc with their
spkg? As far as I can tell, there are no guidelines anywhere (please
correct me if I am wrong) for devopers to watch out for. Here are some
suggestions for spkg developers:

1. Be very very careful about modifying existing Python or Cython
files in the Sage devel tree. This will (AFAIK) affect every clone
built after your spkg is applied and may make it difficult or
impossible to create patches for the file(s) you changed.

2. Be very very careful about modifying other existing spkgs. The spkg
you touched my need to be reinstalled. However, without reading the
install log, the person installing your spkg will not know what other
spkg's were affected. (Example: The experimental 4ti2 overwrites
Nathann Cohen's GLPK spkg with a much older GLPK. I would have been
very confused if Marshall Hampton did not suggest that I post the
install log to a failure I was getting for his 4ti2 spkg. I discovered
this behaviour while reading the log Marshall requested.)

It is a basic rule of GAP that no package can "significantly change"
the current behaviour of GAP. (I hesitate to call it an axiom, since I
think exceptions can be made if Steve Linton approves.) I don't have a
good definition of "significantly change". Basically, if a calculation
can be done before the package is applied (I call this "current
behaviour") then you should get the same, or an equivalent, result
afterwards. Is it reasonable that a similar rule be adopted for Sage?
If so, I think the above two suggestion imply this "no change" rule.
However, I think they are stronger, since I think suggestion #1 also
affects how clones can be corrupted by an spkg.

- David Joyner

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an 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