I thought I was going to misrepresent stuff, but may be not to that extent.
If we fork polybori I do not see the point of patching it for sage on top of the fork. (3) is very much out as far as I am concerned. François > On 11/06/2015, at 14:08, R. Andrew Ohana <andrew.oh...@gmail.com> wrote: > > > > On Wed, Jun 10, 2015 at 6:40 PM, François Bissey > <francois.bis...@canterbury.ac.nz> wrote: > Hi all, > > over at http://trac.sagemath.org/ticket/18437 we have > some heated debate about what to do about polybori. > > Let me summarize the situation. > * at this moment polybori is dead upstream > * polybori is the last package using scons > * is one of the last packages, if not the last, not > ready for python 3.x > * polybori is actually python wrapper over another > package called CUDD which is included in polybori > and "scons-ified". > > This is a off, polybori is its own c++ library -- cudd is merely a dependency > (and polybori doesn't even use much of it). It is true that polybori ships > its own version of cudd (almost certainly because cudd's build system is > atrocious). > > > There is a strong debate about what to do about > the situation. > > * fork upstream and keep it as a separate package but > no one really wants to be the maintainer. > > I think Jeroen and I agree that we need to fork polybori -- the debate is > more in the details. > > > * autotool CUDD (Andrew Ohanar prodded upstream to > see if they would be willing to adopt any autotooling > we provide without answer so far) > > Upstream cudd has gotten back to me now, they are apparently planning a new > release sometime this summer which uses autotools for its build system. > > and move the > python binding in sage itself making its maintenance > a shared task amongst sage dev. CUDD would become > a standard package to replace polybori. Note it is > currently shipped inside polybori so it is not something > new. > > * Hybrid in between those two. > > More details on the ticket. I would very much would > go with autotooling CUDD and move the wrapper. > The fork of polybori would also move to autotool > as its build system at this stage. > > Because of strong opinions on the ticket and the burden > of the various options, Jeroen pointed out that we > should get some kind of consensus here before moving > forward. > > So we would very much want to hear from other devs > on what to do with polybori. > > Francois > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > > The main debate is around what we should do with the python bindings for > polybori. From the ticket: > > """ > As I see it there are three routes we could go with polybori: > • We adopt the route that we took with Pynac (as a fork of Ginac). Our > fork might in the future become tightly coupled with Sage, but we maintain it > as a separate package outside of Sage. > • We make a minimal fork, only include the minimal changes necessary to > build polybori without scons. If more substantive changes are needed, we > include those in the Sage library. > • A hybrid approach: maintain a minimal fork, and a maintain a set of > patches for more substantive changes. > """ > I would personally vote for 1 or 2, and very much against 3. Some pros and > cons of the various proposals I mentioned: > Pros of 1: > > • We already have pursed this model with Pynac. > • It allows us to modify the c++ code in polybori if we need to. > Cons of 1: > • Maintenance of Pynac has lapsed as people have gotten busy. > • (From Jeroen) It isn't held to the same standard as our normal review > process for Sage. > > > Pros of 2: > > • It distributes the burden of maintenance across the whole Sage > community (in particular, it is easier for a Sage contributor to work on) > • Polybori's bindings does things a bit differently if it is in a Sage > environment (we included polybori before it had python bindings) > > > Con of 3: > > • Maintaining patches is more work than maintaining a forked version of > the code (especially when upstream is dead). > > > If anybody has any better suggestions or thoughts on the matter, I would be > very open to hear them. > > For what its worth, the hard part of making the autotools based build system > is done (at least for the components of polybori that Sage uses). At this > point it is mainly a matter of how we want to deal with the python bindings, > which will need to be updated to work with python 3. > > -- > Andrew > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
