The future of polybori

[François Bissey]

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".

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.

* autotool CUDD (Andrew Ohanar prodded upstream to
see if they would be willing to adopt any autotooling
we provide without answer so far) 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

[R. Andrew Ohana]

On Wed, Jun 10, 2015 at 6:40 PM, François Bissey <francoi...@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+...@googlegroups.com.
To post to this group, send email to sage-...@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

[kcrisman]

I have absolutely nothing invested in this, but I am curious about whether bringing (as much as possible of) polybori into the Sage library or extcode-successor or something would help people revivify the project?  I don't know how many people there are out there who would be potentially interested, whether or not it is a separate package.

The Pynac difficulties are indeed worth mentioning - and note that Ginac does have a live, if not extremely active, upstream.

[Francois Bissey]

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

[William Stein]

Hi,

Can somebody (say at least 3-5 people) who actually *use* polybori on
a somewhat regular basis make some supporting remarks? I personally
have used polybori for anything, nor do I really know of anybody else
who has. If there aren't at least a few people who use it regularly,
then we should consider making it an optional package.

I looked for a minute or two at
https://groups.google.com/forum/#!searchin/sage-support/polybori but
what I saw was about troubles arising from trying to build Polybori,
not from people actually using it.

I could easily imagine Andrew and Francois and Jereon are all
dutifully imagining that I know all kinds of Polybori enthusiasts and
there are good reasons that Polybori really must be really well
supported in Sage. However, it turns out this at least isn't clear to
me.

-- William

--
William (http://wstein.org)

[François Bissey]

On 06/11/15 14:39, William Stein wrote:
> I could easily imagine Andrew and Francois and Jereon are all
> dutifully imagining that I know all kinds of Polybori enthusiasts and
> there are good reasons that Polybori really must be really well
> supported in Sage. However, it turns out this at least isn't clear to
> me.

I wouldn't make that assumption. One of potential problem is that
polybori has small tentacles in other part of sage (crypto) besides
rings/polynomials and surgery to remove it or make it optional won't be
painless.
We may be relying on polybori much more than it appears on the surface.

Francois

[William Stein]

On Wednesday, June 10, 2015, François Bissey <francoi...@canterbury.ac.nz> wrote:

On 06/11/15 14:39, William Stein wrote:

I could easily imagine Andrew and Francois and Jereon are all
dutifully imagining that I know all kinds of Polybori enthusiasts and
there are good reasons that Polybori really must be really well
supported in Sage.  However, it turns out this at least isn't clear to
me.

I wouldn't make that assumption. One of potential problem is that
polybori has small tentacles in other part of sage (crypto) besides
rings/polynomials and surgery to remove it or make it optional won't be
painless.

Good question.  That functionality would just become optional though the Cython build dependency issue could make it hard. 

 

We may be relying on polybori much more than it appears on the surface.

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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
Sent from my massive iPhone 6 plus.

[Ralf Stephan]

There is not much difference between 1 and 2 because, while there is no review mechanism for Pynac admin commits on github, it's on trac instead. And the real problem is always the language barrier: adding C++ to an already huge skillset is too much for many authors and most reviewers, regardless of if a package is patched or a patch to a package is patched.

Regards,

[William Stein]

On Wednesday, June 10, 2015, Ralf Stephan <gtr...@gmail.com> wrote:

There is not much difference between 1 and 2 because, while there is no review mechanism for Pynac admin commits on github, it's on trac instead. And the real problem is always the language barrier: adding C++ to an already huge skillset is too much for many authors and most reviewers, regardless of if a package is patched or a patch to a package is patched.

Even if you know C++ well, it is a much more difficult language than Python.  Or at least it is not hard to write modern  C++ that is very difficult for others to work on. 

 

Regards,

--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--

[Jeroen Demeyer]

On 2015-06-11 03:40, François Bissey wrote:
> * fork upstream and keep it as a separate package but
> no one really wants to be the maintainer.

If it's decided that we are allowed to fork polybori, can this be
applied to other packages too?

I have often been frustrated in Sage by people complaining that we
should stay as close to upstream as possible, that we shouldn't patch
packages in Sage, that we should stick to release (non-development)
versions of packages in Sage.

Most recently for example in #18450 I was forced to rewrite part of a
patch because upstream Cython didn't want to accept a patch (I still
think that my patch was reasonable and I don't understand why upstream
doesn't like it).

And every time I make a change to PARI, I feel resistance because we're
moving further away from the released PARI version.

So I hope that you understand my frustration if other people can do with
polybori what they want but I constantly hit walls because I am not
allowed to patch other packages.

Really, I wish we could just give up on this whole "packaging Sage for
distributions" effort.


Jeroen.

[Julien Puydt]

Hi,

I can hardly disagree more.

That basically means that instead of working on sagemath, sage devs will
end up working on keeping hundreds of more or less nonsensical forks,
with hundreds of hostile upstreams.

Open software is about cooperation.

Snark on #sagemath

[Martin Albrecht]

Hi all,

I use it. Not as much as I used to (my research moved on) but it would be
rather if it was gone. I also know that some people in my field use it, i.e.
the BooleanPolynomialRing. If that was gone, we'd go from okay-ish to hell-ish
for computing with an object which quite naturally arises in crypto and
related fields.

I'm also up for helping out with maintenance:

> 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.

Being ignorant of some of the issues around Pynac, (1) would allow us to
attract outside contributions more easily. Not sure how realistic that is,
though. I'll point some of the usual suspects to this thread, let's see what
happens.

Cheers,
Martin

[Francois Bissey]

I am only proposing to fork a package with a dead upstream. I wouldn’t do it
with a live one. Nevertheless I understand that it makes me look like I am
saying two contradictory things at the same time.

To be clear with a rant of my own. If you fork a live project you’ll have to live
with the divergence and have to make a choice of using one or the other.
You may as well rename the thing if you are going to fork and diverge, that’s
being honest.

You don’t have to deal with the potential for divergence with a dead project.
You are only diverging with the old dead body the same way that you may diverge
from version 1 to version 2 of a software, but there will not be a competing branch
for the new version you release. A name change is probably still a good idea
to signal new ownership.

François

[Francesco Biscani]

Or at least it is not hard to write modern  C++ that is very difficult for others to work on. 

Isn't it true for most languages? I have seen nested list comprehension one-liners in Python that make my skin crawl.

[john_perry_usm]

On Wednesday, June 10, 2015 at 11:12:53 PM UTC-5, William wrote:

Even if you know C++ well, it is a much more difficult language than Python.  Or at least it is not hard to write modern  C++ that is very difficult for others to work on. 

To be fair, I recall people complaining that "pre-modern" C++ was difficult to work on (not just I). :-)

john perry

[mmarco]

Upstream being dead, the only alternative to forking is to live forever with a fixed version. That might work for the moment, but eventually we will find issues with newer compilers, or newer version of the libraries it deppends on, or the newer version of python....  And at that point forking will be the only way to go on. 

So, from my point of view, the question is if we should fork polybory, but if we are going to do so now or later.

Unless of course in the meantime we find an alternative to polybory, but i wouldn't count on that.

[Alexander Dreyer]

From my point of view a fork - or better call it sequel - would be the best.

Unfortunately, all original developers like me went to industrial positions, which are completely unrelated to PolyBoRi or any kind of algebraic software.
Meanwhile, family and the new jobs don't leave us time to work on pet projects. So, the real active branch is the ohanar github repository.

At that repository, I already see great work in autotools support. I would adopt this for sure if I ever get the chance to get back to work on PolyBoRi. For the unlikely case of sudden freetime I would rather contribute to the new project than trying to resurrect the old one. ;-)

However, to avoid confusion, you should rename your fork. Use TOSSFKAP or BRiAl or whatever you like to distinuish the projects.

Also, I have to note, that in the autotools branch some headers from original Cudd were reintroduced. This might be a problem since some were intentionally left out due to unclear licenses. This had been suggested by the debian people some time ago.

Best regards and good luck,
Alexander

[Alexander Dreyer]

PS: Perhaps I should admit that PolyBoRi is dead. It's a hard year: Spock, Winnetou, Dracula - and now PolyBoRi - died.

[Ralf Stephan]

So folks, be careful when you fork---you might end up as maintainer.

[William Stein]

On Thursday, June 11, 2015, Ralf Stephan <gtr...@gmail.com> wrote:

So folks, be careful when you fork---you might end up as maintainer.

Good point.  I think we should either 

1. Remove polybori or

2. Have a specific person (or persons) step up to be maintainer.

I'm fine with either option.  

 

--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--

[Martin Albrecht]

I started talking to some people from the symbolic computation community to
discuss options (e.g. if someone wants to take over maintenance). Hence, don't
rush to a conclusion please, I'd really like to keep PolyBoRi around somehow
but don't want to be (sole) maintainer.

Cheers,
Martin

On Thursday 11 Jun 2015 20:45:41 William Stein wrote:
> On Thursday, June 11, 2015, Ralf Stephan <gtr...@gmail.com> wrote:
> > So folks, be careful when you fork---you might end up as maintainer.
>
> Good point. I think we should either
>
> 1. Remove polybori or
>
> 2. Have a specific person (or persons) step up to be maintainer.
>
> I'm fine with either option.
>
> > --
> > 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+...@googlegroups.com <javascript:;>.

> > To post to this group, send email to sage-...@googlegroups.com

> > <javascript:;>.

> > Visit this group at http://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
--

.www: https://martinralbrecht.wordpress.com
.pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4
.xmpp: martinr...@jabber.ccc.de
.twitter: https://twitter.com/martinralbrecht
.keybase: https://keybase.io/martinralbrecht

[Jeroen Demeyer]

On 2015-06-11 10:31, Julien Puydt wrote:
> Open software is about cooperation.

Of course. The question is: what should we do if upstream does not want
to cooperate? I don't want to call names in this thread, but I have
proposed patches to many upstream projects which are part of Sage
(usually they are small bugfixes). The chances of actually getting a
patch accepted by upstream are unfortunately much smaller than I would wish.

Some people think that Sage should only add patches to upstream packages
if they are accepted by upstream. This is frustrating, because it really
slows down Sage development.

Jeroen.

[William Stein]

On Friday, June 12, 2015, 'Martin Albrecht' via sage-devel <sage-...@googlegroups.com> wrote:

I started talking to some people from the symbolic computation community to
discuss options (e.g. if someone wants to take over maintenance). Hence, don't
rush to a conclusion please, I'd really like to keep PolyBoRi around somehow
but don't want to be (sole) maintainer.

Thanks!!   

 

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.

Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--

[Francois Bissey]

> On 12/06/2015, at 21:18, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>
> On 2015-06-11 10:31, Julien Puydt wrote:
>> Open software is about cooperation.
> Of course. The question is: what should we do if upstream does not want to cooperate? I don't want to call names in this thread, but I have proposed patches to many upstream projects which are part of Sage (usually they are small bugfixes). The chances of actually getting a patch accepted by upstream are unfortunately much smaller than I would wish.
>

That’s very unfortunate, you expect some rejections but your report of low
number is still annoying.

> Some people think that Sage should only add patches to upstream packages if they are accepted by upstream. This is frustrating, because it really slows down Sage development.
>

Having been around sage since 2007, I have accepted the fact that not
all of the patches in sage will be upstreamed. Even at a linux distro level
that’s a pipe dream - have you seen the list of patches that go into your distro?
How many of these will be accepted upstream? Probably less than you would
imagine.

Nevertheless, it is uncomfortable, I am sure that I have been one the people
that prompted that remark, it is even written somewhere on trac.

There are weighted decisions and I do not want to be painted all black or
white. I am the sage-on-gentoo maintainer and anything that is not accepted
in the main Gentoo tree, I carry it in my tree and the maintenance is mine to do.
If the package is only in my tree, I won’t be fussy adding sage patches.

If the package is in the main tree and widely used, well the barrier for entry
of the patch to the main tree has just dramatically increased, even more so
if 1) it is not accepted upstream 2) it adds a “feature” rather than fix something
that will break for many people (the line between feature and bug may sometimes
be blurry). In that case, I will carry a fork of the distro package with all the burden
that implies when trying to maintain coherence with the distro and steal the main
tree own various fixes (it’s been a while since sage-on-gentoo has relied on
maxima from the main tree…).

So I am looking at sage trac and I see one of those major, widely used, package
and upstream reject the patch. Do I want to review the inclusion? Well it is a
bit like asking if I am a masochist (considering how long I have been doing
sage-on-gentoo it is a really good question). So on that principle I won’t review it.
Someone else may review it positively, I am not the only reviewer available after
all, and then I’ll have to do my masochistic bit anyway.

May be Jeroen is right, may be I should cut the middle man and do the review
anyway.

François

[Julien Puydt]

Hi,

Nothing will slow development down like dozens of forked packages to
maintain, especially if upstreams consider you hostile.

There's a joke around here which one could translate as "The fastest and
shortest way down is off the cliff -- I prefer hiking!"

Snark on #sagemath

[Martin Albrecht]

Hi,

so, the Singular team *wants* to keep PolyBoRi alive, but it's currently not
clear if and when they *can* devote resources to it. This will be clarified
over the next few months it seems.

Cheers,
Martin

[Jeroen Demeyer]

On 2015-06-12 14:34, 'Martin Albrecht' via sage-devel wrote:
> Hi,
>
> so, the Singular team *wants* to keep PolyBoRi alive, but it's currently not
> clear if and when they *can* devote resources to it. This will be clarified
> over the next few months it seems.

Doesn't OpenDreamKit help with this?

[Jeroen Demeyer]

On 2015-06-12 14:32, Julien Puydt wrote:
> Nothing will slow development down like dozens of forked packages to
> maintain, especially if upstreams consider you hostile.

If you mean "forking" in the serious sense, you're probably right.

If you mean "forking" as in "add a few patches", then you're surely
wrong: Sage has always added many patches to various upstream project
and that was never a burden to development.

[Paulo César Pereira de Andrade]

2015-06-12 6:18 GMT-03:00 Jeroen Demeyer <jdem...@cage.ugent.be>:
> On 2015-06-11 10:31, Julien Puydt wrote:
>>
>> Open software is about cooperation.
>
> Of course. The question is: what should we do if upstream does not want to
> cooperate? I don't want to call names in this thread, but I have proposed
> patches to many upstream projects which are part of Sage (usually they are
> small bugfixes). The chances of actually getting a patch accepted by
> upstream are unfortunately much smaller than I would wish.

I understand your frustration.
I understand that sage needs to bundle all it needs because otherwise it
would be pretty much impossible to install sage on old, or too new systems.
But keeping as close as possible to upstream is really desirable. For example,
I have some patches in a few packages in Fedora, to satisfy sage, but for
others it is not easy... Right now, Fedora has sagemath 6.5 packaged, and
I need to find some time to see if reasonable, and how I would patch sage
to use a non released and patched pari, to update to 6.7 (skipping 6.6).

> Some people think that Sage should only add patches to upstream packages if
> they are accepted by upstream. This is frustrating, because it really slows
> down Sage development.
>
> Jeroen.

Thaks,
Paulo

[R. Andrew Ohana]

On Thu, Jun 11, 2015 at 2:42 PM, Alexander Dreyer <jan.alexan...@gmail.com> wrote:

From my point of view a fork - or better call it sequel - would be the best.

Unfortunately, all original developers like me went to industrial positions, which are completely unrelated to PolyBoRi or any kind of algebraic software.
Meanwhile, family and the new jobs don't leave us time to work on pet projects. So, the real active branch is the ohanar github repository.

At that repository, I already see great work in autotools support. I would adopt this for sure if I ever get the chance to get back to work on PolyBoRi. For the unlikely case of sudden freetime I would rather contribute to the new project than trying to resurrect the old one. ;-)

However, to avoid confusion, you should rename your fork. Use TOSSFKAP or BRiAl or whatever you like to distinuish the projects.

Yes, I agree, I just didn't have a good name. Do you have a particular favorite (and we could just use that).

Also, I have to note, that in the autotools branch some headers from original Cudd were reintroduced.

Which ones exactly? I exported the mercurial repository into git and double checked the files, but didn't notice any new headers.

 

This might be a problem since some were intentionally left out due to unclear licenses. This had been suggested by the debian people some time ago.

Best regards and good luck,
  Alexander

--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--

Andrew

[R. Andrew Ohana]

On Fri, Jun 12, 2015 at 5:34 AM, 'Martin Albrecht' via sage-devel <sage-...@googlegroups.com> wrote:

Hi,

so, the Singular team *wants* to keep PolyBoRi alive, but it's currently not
clear if and when they *can* devote resources to it. This will be clarified
over the next few months it seems.

What about this:

Now: We work on making polybori an optional package in sage.
  * At least going by this thread, the number of people who use polybori in Sage is small enough for it to make sense to have polybori as an optional package.
  * (I looked into this before I did the autotoolization) It shouldn't take too much work to optionalize polybori -- the main effort will be its uses in the crypto code.

  * Polybori is the sole dependency of Sage that doesn't at least build against python 3 -- getting past this last major hurdle will make it much easier to work on porting the actual sage library to python 3.

Future: The Singular team or whoever dedicates the time to maintain a sequel to polybori.

  * This will be required once we stop supporting python 2 in the very distant future (at least after 2020, which is the EOL for python 2).

 

Cheers,
Martin

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.

Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--

Andrew

[Martin Albrecht]

Hi all,

On Friday 12 Jun 2015 13:45:05 R. Andrew Ohana wrote:
> What about this:
>
> Now: We work on making polybori an optional package in sage.
> * At least going by this thread, the number of people who use polybori in
> Sage is small enough for it to make sense to have polybori as an optional
> package.

I know I might be outvoted and I haven't volunteered to just do the work, but
I very much disagree with this. Dropping PolyBoRi as a default package makes
Sage *a lot* less useful for me.

Why does this need to happen now?

> * (I looked into this before I did the autotoolization) It shouldn't take
> too much work to optionalize polybori -- the main effort will be its uses
> in the crypto code.
> * Polybori is the sole dependency of Sage that doesn't at least build
> against python 3 -- getting past this last major hurdle will make it much
> easier to work on porting the actual sage library to python 3.
>
> Future: The Singular team or whoever dedicates the time to maintain a
> sequel to polybori.
> * This will be required once we stop supporting python 2 in the very
> distant future (at least after 2020, which is the EOL for python 2).

Martin

[Francois Bissey]

> On 13/06/2015, at 22:00, 'Martin Albrecht' via sage-devel <sage-...@googlegroups.com> wrote:
>
> Hi all,
>
> On Friday 12 Jun 2015 13:45:05 R. Andrew Ohana wrote:
>> What about this:
>>
>> Now: We work on making polybori an optional package in sage.
>> * At least going by this thread, the number of people who use polybori in
>> Sage is small enough for it to make sense to have polybori as an optional
>> package.
>
> I know I might be outvoted and I haven't volunteered to just do the work, but
> I very much disagree with this. Dropping PolyBoRi as a default package makes
> Sage *a lot* less useful for me.
>
> Why does this need to happen now?

Because it is a major blocker to getting sage ported to python 3.x.
That’s currently the only dependency that doesn’t build with python 3.x.
This is also the only thing using scons another currently python2 only thing
that we very much want to ditch.

François

[Martin Albrecht]

Hi all,

FYI, I put this out. Let's see if there *are* other users besides me:

https://martinralbrecht.wordpress.com/2015/06/13/polybori-is-dead-it-needs-your-help/

Cheers,
Martin

[Martin Albrecht]

Okay, so the problem is that the Sage library cannot be ported to Python 3
unless PolyBoRi is? That makes sense.

As a corollary this would also mean that making PolyBoRi an optional package
would mean to drop it entirely as it wouldn't work as soon as the transition
to Python 3 is here (?)

Cheers,

[Francois Bissey]

I am not sure we will just transition to python 3.x and just drop python 2.7.
There will probably be a period where we work on both python 3.x and 2.7.
Of course 3.x will get more and more attention over time. But while
sage is buildable with python 2.7, polybori could be used with it.

I think Andrew has already done quite a bit of the porting to autotools and
some python 3 fixes. But neither he or I want to be a maintainer - at least
for the long term.

François

[mmarco]

I am  pretty much with Martin here (although i guess he uses polybory far more often than i do). I don't know much about autotools, but i can try to give a small hand on that and the python3 part. I hope with the arrival of July i will have some spare time for that.

I am also considering attending to the following Sage days in August. If somebody else is interested in that, we could try to work on that there.

[Martin Albrecht]

Hi all,

On Saturday 13 Jun 2015 10:41:15 Francois Bissey wrote:
> I think Andrew has already done quite a bit of the porting to autotools and
> some python 3 fixes. But neither he or I want to be a maintainer - at least
> for the long term.

ah, sorry that I missed that. Great! How about this:

1. We create an organisation on GitHub PolyBoRi3

2. We move Andrew's current version over there

3. I volunteer to be *a* maintainer, help would greatly be appreciated

I envision that it would be good to split PolyBoRi up roughly as follows to
make maintenance simpler (please do tell me if this is silly). This way we
keep dependencies of Sage as external dependencies and don't have to suck
large parts into the Sage library proper:

- polybori-core (libpolybori, Cudd, groebner (?))

the C++ stuff that doesn't involve python at all. This would be a standard
package in Sage (hopefully) and autotoolised.

- polybori-python-binding-boost (PyPolyBoRi)

the C++ boost stuff which does the Python bindings. This is not used by Sage -
I believe - so we don't care much. Autotoolised, but not a priority, because
Sage has its own Cython bindings reimplementing this stuff.

- polybori-python

The Python stuff which can be managed by distutils or whatever the kids are
using now. This could in principle be an optional package, but I guess it
might as well be standard given that's pure python and relatively small.

[Jean-Pierre Flori]

Your plan does look good to me Martin.
Just note it won&t be trivial.

[Alexander Dreyer]

@Andrew Sorry, your Cudd sources are fine, I misunderstood some commit message.
About naming: I personally would prefer BRiAl, it was on my shortlist for naming the new project 9 years ago. You are free to use it.

@Martin: Thank you for your emergency call at your Blog! Its nice to see that people care about our previous work.

Best regards,
Alexander

[R. Andrew Ohana]

On Sat, Jun 13, 2015 at 5:21 AM, 'Martin Albrecht' via sage-devel <sage-...@googlegroups.com> wrote:

Hi all,

On Saturday 13 Jun 2015 10:41:15 Francois Bissey wrote:
> I think Andrew has already done quite a bit of the porting to autotools and
> some python 3 fixes. But neither he or I want to be a maintainer - at least
> for the long term.

ah, sorry that I missed that. Great! How about this:

1. We create an organisation on GitHub PolyBoRi3 

2. We move Andrew's current version over there

I can do this. I might also rebase a few of the commits while doing so (to ease the review process), and probably rename it to BRiAl as per Alexander's suggestion.

3. I volunteer to be *a* maintainer, help would greatly be appreciated

I can add you to the github organization as an owner when I make it.

I envision that it would be good to split PolyBoRi up roughly as follows to
make maintenance simpler (please do tell me if this is silly). This way we
keep dependencies of Sage as external dependencies and don't have to suck
large parts into the Sage library proper:

- polybori-core (libpolybori, Cudd, groebner (?))

the C++ stuff that doesn't involve python at all. This would be a standard
package in Sage (hopefully) and autotoolised.

The autotoolisation of this stuff is basically done. Mainly the testsuite needs to be included.
 

- polybori-python-binding-boost (PyPolyBoRi)

the C++ boost stuff which does the Python bindings. This is not used by Sage -
I believe - so we don't care much. Autotoolised, but not a priority, because
Sage has its own Cython bindings reimplementing this stuff.

I think the main reason why Sage has its own Cython bindings is mainly historical -- they existed before polybori added their own python bindings. It would probably be a better idea to use polybori's own bindings in Sage -- it makes no sense trying to maintain two sets of python bindings.

- polybori-python

The Python stuff which can be managed by distutils or whatever the kids are
using now. This could in principle be an optional package, but I guess it
might as well be standard given that's pure python and relatively small.

Cheers,
Martin

--
.www: https://martinralbrecht.wordpress.com
.pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4
.xmpp: martinr...@jabber.ccc.de
.twitter: https://twitter.com/martinralbrecht
.keybase: https://keybase.io/martinralbrecht

--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--

Andrew

[Martin Albrecht]

On Sunday 14 Jun 2015 17:21:21 R. Andrew Ohana wrote:
> I think the main reason why Sage has its own Cython bindings is mainly
> historical -- they existed before polybori added their own python bindings.
> It would probably be a better idea to use polybori's own bindings in Sage
> -- it makes no sense trying to maintain two sets of python bindings.

That's not how I remember it (but my memory might not serve me right): As far
as I know PolyBoRi always had Python bindings, but we wanted something in
Cython so it integrates nicely with the rest of Sage. Also, we wanted tight
integration (coercion, inheritance, etc.) some of which should now be easier
due to changes to the Sage code base (e.g. mathematical hierarchy and
inheritance were decoupled).

I agree with the sentiment, though, and the plan: it would entail ripping the
Cython bindings out and refactoring the Sage specific parts.

[Alexander Dreyer]

Right, we started with boost-python to have a language to play with. There was no standalone cython in the first and c++ had not been so well supported by cython then. So, boost was the rapid way to get a small OSS with few dependencies. However, the "middle-end" ;-) is flexible, so the bindings could easily be replaced, which had been done for Sage then. Partially to avoid shipping boost-python and for performace reasons as far as I recall. Nowadays a fork could soley rely on cython, I guess.