[...] toward standard open source practices.
> You mean like in the Linux kernel, which uses a single monolithic git
> repository?
I think you are being sarcastic.
There are very good reasons to supporting both modularization
On Wed, Apr 6, 2016 at 12:51 AM, Volker Braun <vbrau...@gmail.com> wrote:
> On Tuesday, April 5, 2016 at 8:44:45 PM UTC+2, William wrote:
>>
>> [...] toward standard open source practices.
>
>
> You mean like in the Linux kernel, which uses a single monolithic git
> repository?
I think you are being sarcastic. It's hard to tell on the internet.
> Really, modularization is not a useful goal in of itself. And it comes with
> its own sets of issues, see the left-pad fiasco last week when the nodejs
> clown boat caught fire.
There are very good reasons to supporting both modularization and much
more standard approaches to packaging. It's unbelievable to me that
somebody as technically smart as you and knowledgeable about sage and
software doesn't see this as obvious. Since -- based on responses --
almost nobody else in our community seems to get this either, I'll
just forge on and come up with the future approach to sage development
myself (even though I don't want to).
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
This thread is first and foremost about reducing the friction involved in making code that depends on the Sage distribution available to the world.
Regarding your car analogy, sometimes it is far better if we can factor of some pieces of sage as separate libraries that we use, but which are also used outside of sage. For example, cysignals (I think from Malb). The broader community benefits and we also benefit since more people care about the code and work on it. It's a win-win.
Remember that Cython used to be part of Sage and be called SageX... Making it separate was good for everybody.- William
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
On Friday, April 8, 2016 at 1:26:07 AM UTC+2, William wrote:This thread is first and foremost about reducing the friction involved in making code that depends on the Sage distribution available to the world.Whats wrong with the obvious solution: make it a Python package (basically add setup.py) and then "sage -pip install https://github.com/vbraun/awesomepackage.git". Clearly we could have more documentation for how to write the setup.py or some package directory service. But really it is already a one-liner.
Regarding your car analogy, sometimes it is far better if we can factor of some pieces of sage as separate libraries that we use, but which are also used outside of sage. For example, cysignals (I think from Malb). The broader community benefits and we also benefit since more people care about the code and work on it. It's a win-win.Yes but cython and cysignals don't do anything for math directly, they are pure dependencies. By contrast, lets say we break out all elliptic curve stuff into a separate package. Just like with cysignals, this will remove all elliptic curve documentation from the Sage reference manual. Still a win-win?
Remember that Cython used to be part of Sage and be called SageX... Making it separate was good for everybody.- William
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my massive iPhone 6 plus.
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Whats wrong with the obvious solution: make it a Python package (basically add setup.py) and then "sage -pip install https://github.com/vbraun/awesomepackage.git". Clearly we could have more documentation for how to write the setup.py or some package directory service. But really it is already a one-liner.That is exactly what I'm proposing
Yes but cython and cysignals don't do anything for math directly, they are pure dependencies. By contrast, lets say we break out all elliptic curve stuff into a separate package. Just like with cysignals, this will remove all elliptic curve documentation from the Sage reference manual. Still a win-win?1. Not necessarily true.
2. Is it so bad that the Cython docs aren't in the sage reference manual?
Hi,
This was a comment I just put on trac #965: "I would make a completely
separate python package, maybe called pysmalljac, which builds
smalljac and makes it usable from Python. It would be on github and
pypi. That's how most Sage development should be done. What a
monster I've created by following the Magma way of doing things
instead of the standard open source best practices..."
I am recommending to absolutely everybody I talk with about Sage
development that we switch from our current massive monolithic
centralized approach toward standard open source practices. Namely,
lots of smaller libraries, standard open source practices, etc. It
would be really valuable to have a thread on sage-devel about how to
more systematically support this.
Some thoughts:
- For now, work can be done that is valuable but doesn't have to
impact the current sage/trac workflow. For example, somebody might
create an awesome Python package that does BLAH and depends on the
core Sage library (what you get via "import sage" now).
- There are 77989 examples of Python packages at https://pypi.python.org/pypi
- This is pretty useful to read:
https://python-packaging.readthedocs.org/en/latest/
> This thread is first and foremost about reducing the friction involved in making code that depends on the Sage distribution available to the world.
> Based on feedback I get from users, this friction is a very, very significant problem to the growth of Sage.
Let me recall something that comes up often, but that I haven't seen yet in this thread nor at the Sage days. Just two weeks ago I was said: "We are going to make our student write code in Magma, because we want something future proof. We've used Sage a couple of times before, but each time Sage updates break our code in <1yr, and it takes too much work to know why and update our code".
Let me stress that these are highly skilled researchers who develop amazing software and have a very deep knowledge about programming. One of them develops a library that is a core piece of infrastructure for Magma, and which is responsible for a good fraction of the benchmarks where Magma crushes Sage. If we could make these people stick to Sage, I can only imagine benefits for us.
I have this experience myself, though, being more involved in Sage, I make the effort to patch my code to work with the latest stable. At some points in time, it has even been impossible to have code that works both with the latest stable and the latest beta (and/or the version in SMC). This is something that should only happen at major version bumps, if ever.
Of course, this is not easy to solve, but having a more modular distribution (at least for some meaning of "modular") might help.
--
Luca
> if research developers 1) don't care enough about their own code to polish it enough for going through our review process
I don't agree with Dima that putting their code into Sage is what researchers should do, no matter what.
> But then there is nothing to do on the Sage side, this already works and is
> totally standard.
Just because
it is technically possible to do something and documented how to do so
online, doesn't mean there is nothing to do on the sage side.
> Much of the memory usage of the current docbuild is the huge intersphinx
> data, and no amount of modularization would make that smaller.
I disagree. If the elliptic curves docs aren't in Sage at all (say),
then it certainly
isn't going to make that stuff larger.
this "one other problem of Sage is that it does not define
clearly what's the public API and what's internal.
If there were large body of pip-installable packages, which are user
code, this would help *define* what the public API of Sage really is,
and also give us a much larger body of code to test against before
making new releases.
On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote:this "one other problem of Sage is that it does not define
clearly what's the public API and what's internal.IMHO thats just not true; What you get on the commandline (i.e. from sage.all import *) is public and the rest is not. If thats not enough (and really nobody ever asked) we could mark extra imports as public, e.g. by adding special sage.foo.public packages.
If there were large body of pip-installable packages, which are user
code, this would help *define* what the public API of Sage really is,
and also give us a much larger body of code to test against before
making new releases.What API design school is that? You dump code on users and whoever manages to build the most convoluted contraption out of that will determine the future direction of the project ;-) Where is the leadership there? Who is going to handle the testing for each ticket, are you going to do that yourself?
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
On Friday, April 8, 2016, Volker Braun <vbrau...@gmail.com> wrote:On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote:this "one other problem of Sage is that it does not define
clearly what's the public API and what's internal.IMHO thats just not true; What you get on the commandline (i.e. from sage.all import *) is public and the rest is not. If thats not enough (and really nobody ever asked) we could mark extra imports as public, e.g. by adding special sage.foo.public packages.Why does nobody ever ask?If there were large body of pip-installable packages, which are user
code, this would help *define* what the public API of Sage really is,
and also give us a much larger body of code to test against before
making new releases.
What API design school is that? You dump code on users and whoever manages to build the most convoluted contraption out of that will determine the future direction of the project ;-) Where is the leadership there? Who is going to handle the testing for each ticket, are you going to do that yourself?I don't care about design schools. I would much rather be aware of how sage-dependent code is actually being used in the wild than to sit in school blissfully ignorant of how sage is really being used.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Why does nobody ever ask?
What API design school is that? You dump code on users and whoever manages to build the most convoluted contraption out of that will determine the future direction of the project
I don't care about design schools
On Friday, April 8, 2016 at 7:40:02 PM UTC+1, William wrote:
On Friday, April 8, 2016, Volker Braun <vbrau...@gmail.com> wrote:On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote:this "one other problem of Sage is that it does not define
clearly what's the public API and what's internal.IMHO thats just not true; What you get on the commandline (i.e. from sage.all import *) is public and the rest is not. If thats not enough (and really nobody ever asked) we could mark extra imports as public, e.g. by adding special sage.foo.public packages.Why does nobody ever ask?If there were large body of pip-installable packages, which are user
code, this would help *define* what the public API of Sage really is,
and also give us a much larger body of code to test against before
making new releases.testing against sufficiently large body of code which is not maintained by a project is a perfect way to makesure that no new releases are made by the project, ever.
What API design school is that? You dump code on users and whoever manages to build the most convoluted contraption out of that will determine the future direction of the project ;-) Where is the leadership there? Who is going to handle the testing for each ticket, are you going to do that yourself?I don't care about design schools. I would much rather be aware of how sage-dependent code is actually being used in the wild than to sit in school blissfully ignorant of how sage is really being used.I thought that with SMC you have a near-perfect opportunity to see what Sage users use in the wild...
And perhaps, perhaps, the 1st thing would be to get a single-user SMC frontend available as a pip-installable package, so that sagenb can retire, at last?
Dima
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my massive iPhone 6 plus.
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
On Friday, April 8, 2016, Dima Pasechnik <dim...@gmail.com> wrote:
On Friday, April 8, 2016 at 7:40:02 PM UTC+1, William wrote:
On Friday, April 8, 2016, Volker Braun <vbrau...@gmail.com> wrote:On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote:this "one other problem of Sage is that it does not define
clearly what's the public API and what's internal.IMHO thats just not true; What you get on the commandline (i.e. from sage.all import *) is public and the rest is not. If thats not enough (and really nobody ever asked) we could mark extra imports as public, e.g. by adding special sage.foo.public packages.Why does nobody ever ask?If there were large body of pip-installable packages, which are user
code, this would help *define* what the public API of Sage really is,
and also give us a much larger body of code to test against before
making new releases.testing against sufficiently large body of code which is not maintained by a project is a perfect way to makesure that no new releases are made by the project, ever.False. You are simply arguing for ignorance. How we chose to use the results of such testing is up to us to decide.
What API design school is that? You dump code on users and whoever manages to build the most convoluted contraption out of that will determine the future direction of the project ;-) Where is the leadership there? Who is going to handle the testing for each ticket, are you going to do that yourself?I don't care about design schools. I would much rather be aware of how sage-dependent code is actually being used in the wild than to sit in school blissfully ignorant of how sage is really being used.I thought that with SMC you have a near-perfect opportunity to see what Sage users use in the wild...SMC does inform my frustration with the current limitations on Sage development.
And perhaps, perhaps, the 1st thing would be to get a single-user SMC frontend available as a pip-installable package, so that sagenb can retire, at last?SMC is not a Python program.
WilliamDima
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my massive iPhone 6 plus.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
On Sat, Apr 9, 2016 at 2:49 AM, Dima Pasechnik <dim...@gmail.com> wrote:
>> SMC does inform my frustration with the current limitations on Sage
>> development.
>
> I am afraid we see a conflict of interest here.
> It is in interests of SMC that Sage is very, very stable... Frozen.
I want Sage to be (massively) easier to develop and use. I want Sage
usage (and development) to grow beyond its relatively small initial
user group, where it has been stuck since 2010. I think the best
way forward is to trust users and developers further, and support them
with better tools to do development, rather than viewing them as not
worthy of such (" independent fifedoms.... a lot of friction"). My
whole goal with Sage was to give all users as much flexibility and
power as possible, not to centralize authority too much (like with
Magma).
Feedback from users makes it clear they need a stable foundation on
which to build their work, and that -- as much as we imagine we are
providing one -- Sage is not, and things really have got worse (see
Simon King's message). I base this on the feedback in this thread,
and the endless feedback I get from users, and so on.
My proposal is simple: it would be very valuable to support (both
culturally and technically) people creating standalone Python packages
that depend on Sage, developed using current standard open source
practices, which are at this point in pretty good shape.
That's it.
I will continue to recommend to everybody I talk with about Sage
development that we switch from our current massive monolithic
centralized approach toward standard open source practices, as I
mentioned at the beginning of this thread.
It's no doubt very time consuming to check every merged pull request
Sage, unfortunately, hasn't made many pacts in this regard
On Monday, April 11, 2016 at 2:57:16 PM UTC+2, Erik Bray wrote:Sage, unfortunately, hasn't made many pacts in this regardSage does have a very clear way of making symbols available on the commandline, namely via accompanying all.py files. We can either use that to define our public api (which it de facto already is when you use Sage interactively), or go through every module and sprinkle around underscores. Only one of these two is realistic.
Are you proposing to define the public API as just the functions that are available on the command line by default?
On Fri, Apr 8, 2016 at 9:33 AM, Luca De Feo <de...@lix.polytechnique.fr> wrote:
>> How often do you feel that changes in Sage breaks your code?
>
> Looking at my log (this project
> https://github.com/defeo/ss-isogeny-software)
>
> - Sage 6.2: module renamed in Pari/GP interface (without deprecation, as far
> as I recall)
> - Sage 6.4: frankly, I don't know, but possibly a change in the finite
> fields implementation
> - Sage 6.7: changes in cython, not really Sage's fault, I guess
> - Sage 6.7: changes in the finite fields implementation (with proper
> deprecation, this time)
> - Sage 6.10: changes in richcmp (did not get deprecation warnings, but the
> change concerns an internal function)
> - Sage 7.1: affected by #19941 (properly deprecated, note that 7.1 is stable
> right now, but not yet in SMC)
>
> It may be argued that I'm taking risks because I sometimes fiddle with "the
> internals" of Sage, but one other problem of Sage is that it does not define
> clearly what's the public API and what's internal.
+1 -- this "one other problem of Sage is that it does not define
clearly what's the public API and what's internal." is a HUGE problem
-- and we're not aware of it because "user code" is typically private.
If there were a large body of pip-installable packages, which are user
code, this would help *define* what the public API of Sage really is,
and also give us a much larger body of code to test against before
making new releases.
As an example, when working on
https://github.com/williamstein/sage_modabvar
the first thing I noticed in that from sage-6.10 to sage-7.x
import sage.rings.arith
completely BROKE. It became "import sage.arith".
This is (who knows?) a change in the public api of the core sage
library. Maybe it's a gratituous one, and in this case one I'm
puzzled by why this change was made. (I wrote sage.rings.arith in the
first place, and it was meant to be some misc arith needed to
implement rings. Why move it to its own top level module like that?)
By writing Python packages that depend on "the core sage library" we
will be forced to define what the core library is and stabilize it.
If you guys want Sage to survive/thrive, this **MUST HAPPEN**. The
core sage library should -- like with Python -- be the place where
code, which has been tested/used by people and got stable, goes to
stay stable (at least API-wise). Like the standard Python library.
William
>
> Luca
>
> --
> 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 https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
--
William (http://wstein.org)
It doesn't mean that the normal visible
public API of Sage changes
at all. Why do you think otherwise?
We might also be able to make it available
outside Sage, and it could suddenly be of huge value to the Python
world.
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
It doesn't mean that the normal visible
public API of Sage changes
at all. Why do you think otherwise?Well, reading this thread made me think that. Because I don't see how we enforce all those "other pieces" working nicely together, so some would (perhaps quite quickly) drop by the wayside. You are right, as I apparently didn't make clear, that it would be even better to have people more easily able to have separate packages that are quite narrow - and I think that a testing framework like R has would probably suffice for this (as long as breaking such packages was a blocker for release!). (There's also the CRAN versus RForge etc. question...) But I don't see how this is possible with the *current* Sage.> Cars are built out of parts.Yes, parts that are, despite parts suppliers not being the same as the car companies, those parts have high tolerances and highly controlled supply chains. (Or so my brief experience with a parts supplier long ago suggests.) All your examples of "mature open source development" are not the same in their goal as Sage, which apparently aims to have all of mathematics at its fingertips (in the way that Maple and Mathematica, though presumably not Magma or Matlab, seem to).
That's a lot harder to disentangle than the dozen or more R packages I've had occasion to use are, and presumably also the case in non-mathematical software. Modularity in Sage and resolving our import fiasco isn't the same thing as saying that every folder in Sage has to be a separate project, which is what you seem to be implying; though since I misunderstood the very first point, maybe I'm wrong about that too.As an example, take game_theory. This is exactly the kind of "narrow" thing one might think would survive better as a modular bit that could be imported. Which one of the programs in question it relies on (gambit) is, in terms of Python, of course. Yet there is a lot of opportunity with being inside of "real" Sage for them with interconnections with all kinds of other combinatorial and plotting and other stuff that they would be hard put to keep current without being in the Sage library. Having access to all that other math makes the game_theory stuff more powerful. I am skeptical that math can be pared down to just a few pieces that everything else fairly loosely holds fast to.But like I said, if you or ODK or someone else can make this vision happen, as long as the end user still gets the kitchen sink without having to do some wacky import yoga or use possibly-broken packages, I'm not complaining! "I also don't have a problem with things like psage or any other such packages" - and if you're right that my view on that is selection bias, I would be very happy to be wrong. (Well, not really that happy, because people have worked hard and Sage has had weird upgrades that broke their stuff. But you know what I mean.) Bring on the automated testing! :-)
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Well, reading this thread made me think that. Because I don't see how we enforce all those "other pieces" working nicely together, so some would (perhaps quite quickly) drop by the wayside. You are right, as I apparently didn't make clear, that it would be even better to have people more easily able to have separate packages that are quite narrow - and I think that a testing framework like R has would probably suffice for this (as long as breaking such packages was a blocker for release!). (There's also the CRAN versus RForge etc. question...) But I don't see how this is possible with the *current* Sage.> Cars are built out of parts.Yes, parts that are, despite parts suppliers not being the same as the car companies, those parts have high tolerances and highly controlled supply chains. (Or so my brief experience with a parts supplier long ago suggests.) All your examples of "mature open source development" are not the same in their goal as Sage, which apparently aims to have all of mathematics at its fingertips (in the way that Maple and Mathematica, though presumably not Magma or Matlab, seem to).This also seems to be the crux of why some Sage developers are not interested in breaking things up (as opposed to why they actively do not want to break things up) -- namely that Sage should be a monolithic application just like the Maple and Mathematica, and that is all it should be.While in the early days a lot of Sage's functionality was simply wrapping other open source libraries, now there is quite a bit that can only be found in Sage's library -- it seems to me only like the right thing to do to make it so that others in the open source community could easily benefit from our work just like we have benefited from theirs.This doesn't conflict with our mission statement, as it is still perfectly possible to create a interactive shell with tons of functionality from a collection of libraries (again, Sage started as this).As for the technical concerns of having a modular library, it seems the biggest worry is that it will be too hard to orchestrate all of the inter-dependent components of Sage. At this point, I'm not too concerned on this front -- many projects in the past have solved these sorts of issues and I don't think Sage is special in this regard. I would want to see a more formal technical proposal (something along the lines of a SEP) before I would feel comfortable criticizing such a proposal.
As for the technical concerns of having a modular library, it seems the biggest worry is that it will be too hard to orchestrate all of the inter-dependent components of Sage. At this point, I'm not too concerned on this front -- many projects in the past have solved these sorts of issues and I don't think Sage is special in this regard. I would want to see a more formal technical proposal (something along the lines of a SEP) before I would feel comfortable criticizing such a proposal.
I think these are some thoughtful comments, but I also think this is
partly missing the point. This discussion isn't (necessarily) about
how Sage is packaged and presented for the average user. One can
certainly put together a metapackage containing all the bells and
whistles and optional dependencies that one would ever (and never)
need.
I disagree that Sage is all that special. Or at least, I don't
believe there's any need for it to be, whether or not it is currently.
On 14 April 2016 at 15:51, Erik Bray <erik....@gmail.com> wrote:I disagree that Sage is all that special. Or at least, I don't
believe there's any need for it to be, whether or not it is currently.If the past is any indication, you will find some cultural resistance about this point in the Sage community. Sometimes it seems like Sage lives in a reality distortion field in which normal software development practices do not apply :)William's change of heart about modularization is a relatively recent development, which - I speculate - might have been brought forward by his increased involvement with the Python (and non-Python) ecosystems while working on SMC.
FWIW, I think you are doing the right thing and wish you all the best luck in the effort :)Cheers,Francesco.
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Chris -- who wrote abelfunctions -- is a Univ of Wash grad student I
know. I recently ran into him and he told me that he had spent years
writing this package as a standard Python package depending on sympy
(mainly) and not Sage. However, it was getting quite frustrating to
finish abelfunctions, due to him needing things that are in Sage (I
think things like interval arithmetic?). He didn't want to develop
his code in a way that depended on Sage, because he wanted it to be
more widely available, and he clearly didn't see the value in having
the code packaged as part of Sage for only a few small things. This
is a great example of how our centralized monolithic approach is
overall not the best for the community at large.
I've cc'd Chris in case he wants to clarify this, since I might not
understand.
> These packages are nearly impossible to found from the sagemath website!
Chris -- who wrote abelfunctions -- is a Univ of Wash grad student I
know. I recently ran into him and he told me that he had spent years
writing this package as a standard Python package depending on sympy
(mainly) and not Sage. However, it was getting quite frustrating to
finish abelfunctions, due to him needing things that are in Sage (I
think things like interval arithmetic?). He didn't want to develop
his code in a way that depended on Sage, because he wanted it to be
more widely available, and he clearly didn't see the value in having
the code packaged as part of Sage for only a few small things. This
is a great example of how our centralized monolithic approach is
overall not the best for the community at large.