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: 1. 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. 2. 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. 3. 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.
