Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?
On Thursday, April 27, 2023 at 1:24:01 AM UTC-7 Dima Pasechnik wrote: The next in line will be jupyter and friends. I agree with this point; specifically the front-end parts of Jupyter/JupyterLab, which run in a separate Python process (and therefore can be installed in a completely separate tree / venv). For this idea, we have the the long-open metaticket https://github.com/sagemath/sage/issues/30306 But this observation can be generalized. For any package from which we only use executables or data, not a shared library, we can install it in any way we want -- without compromising the Sage distribution's ability to use already installed system packages. So we can switch from our own installation scripts to using conda-forge for these! I've written up the details in https://github.com/sagemath/sage/issues/35583 I'm counting about 40 packages (not counting the Jupyter frontend components) for which we can make a safe and easy withdrawal from packaging activities, WITHOUT making the Sage distribution harder to install, and avoiding the "concave cost" along the path that I mentioned. (Note that gcc/gfortran do not fall into this category of packages because of their runtime library components.) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/76ee02da-b86d-4d83-975e-27db5ca6b130n%40googlegroups.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Fri, 2023-04-28 at 18:06 +0100, Dr. David Kirkby wrote: > > To me at least, it would be unwise not run the test suite. > > If you are choosing to use 15-20 year old hardware, you can not reasonably > to handle a large modern program like Sagemath. More modern machines than > that get thrown in skips. 😂 > I have ~1,000 other modern packages built from source on these machines and hack on many of them. The hardware is as fast as the day I bought it. The issue is not that sage is modern, rather that it's still built like a pet project from 2005. The test suite is an entirely different topic where your criticism is more valid. There are a few different issues there, all pretty irrelevant to this discussion: * We have many redundant tests * Doctests inherently require redundancy and are relatively slow * We have tests for bugs that were fixed in upstream projects and are already checked by the upstream test suite * The "too long" warning is outrageously high * The "too long" warning uses "wall time", which is meaningless as an objective measure of how much computation is done. Someone with newer hardware can easily introduce a "fast" test that takes over a minute for me to run. Beyond that, whatever time it takes to run the test suite is necessary and I'm not complaining about it. It's the unnecessary bit that's annoying. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2e79d3741ff8b5ac98dff01373c6c4ff53f7f42c.camel%40orlitzky.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thu, 27 Apr 2023 at 15:49, Michael Orlitzky wrote: > > The test suite can take another full day to run -- some of > that is useful, but a lot is not. This is the biggest impediment to the > use and development of sage on an old system. To me at least, it would be unwise not run the test suite. If you are choosing to use 15-20 year old hardware, you can not reasonably to handle a large modern program like Sagemath. More modern machines than that get thrown in skips. 😂 Dave. > -- Dr. David Kirkby, Kirkby Microwave Ltd, drkir...@kirkbymicrowave.co.uk https://www.kirkbymicrowave.co.uk/ Telephone 01621-680100./ +44 1621 680100 Registered in England & Wales, company number 08914892. Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United Kingdom -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CANX10hCrQKo6_1pCiO3x_4XG_t1Lo_ra4QMERBVc9yLLBrRCpg%40mail.gmail.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thursday, April 27, 2023 at 2:54:47 PM UTC-7 Isuru Fernando wrote: I guess there are several requirements we need 1. Support for all major OS/architecture combinations 2. Easy to build for rare OS/architecture combinations 3. Possible to install as a non-root user 4. Binaries are available for non-root This is a good list. We also need to agree about what fits into category 1. As far as platforms for developers are concerned, does plain OS X count, or plain OS X + Xcode command-line tools, or OS X + homebrew, or OS X + conda, etc.? AFAIK, there's no package manager that has all 4 above and we will have to pick which requirements are more important than others. Isuru -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/0a85f27c909f8d8f185801af2228e6331bcad544.camel%40orlitzky.com . -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/131f110d-5862-4149-b49e-c4500b86cb4en%40googlegroups.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
(I'm planning upgrades in the next year or two, but it will be to relatively low power RISC-V hardware. There are moral, legal, environmental, and other non-financial reasons why people use "old" hardware. But of course the financial reasons are very real too.) Agreed on all points. Access reasons too. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/bda86cae-9077-437f-9cf4-72cef997d85bn%40googlegroups.com.
Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released
On Thu, 2023-04-27 at 12:37 -0700, Matthias Koeppe wrote: > A problem only arises when you try to build a bleeding-edge sage on an older > stable distro -- an undertaking unsupported by most projects. > > Is it? I would say that Sage is very special in this regard because of its > extreme number of complicated dependencies; and because of its > long-standing goals of empowering the members of the user community to > become contributors. "Unsupported" was too strong, but a lot of large projects expect a higher level of sophistication from developers than users. For example, you're expected to have the latest GNUlib or autotools installed, or perhaps the latest LLVM, and a concoction of obscure test-suite dependencies. Gentoo stable is still on openssl-1.1, and I've had to put 3.x in /usr/local a few times to build projects that got tired of adding #ifdefs. This does... interact... with the goal of making it easy to contribute. But the complexity of the sage distribution and build system also makes it harder to use and develop sage. > But this creates a serious barrier: If Sage development can only be done on > bleeding-edge distributions, new Sage developers need to abandon their > current distribution. That's really bad. I agree, and "unsupported" carried the wrong connotation. You can certainly develop on those distros, but you're responsible for obtaining the dependencies. You can find them in a third-party rpm/deb repo, or build them in /usr/local, or install them with Nix/Conda/Guix. How difficult this is depends on how deeply the dependency is embedded in the tree. You know this, but for the sake of the list: you can't build only a local copy of PARI, you have to build local copies of anything else that will be linked to both PARI and sage. Otherwise it'll crash when you load both PARIs into the same process. In contrast, a python package at the edge of the graph can be installed locally with only a "pip install". We should take that into account when deciding how important backwards- compatibility is for a given package; there's no silver bullet. > Anyone bothered by this can of course send us patches that extend > compatibility to older PARI. > > Would we welcome such patches? When we upgrade a package such as PARI, > typically very experienced Sage developers have already assessed how easy > it would be to keep the old version supported. When it is decided to drop > support, it is often not because we don't know how to support both but > rather because we do not want to have more complicated code in Sage. We would have to take into account that breaking compatibility will force people on old distros to build local copies of not only pari, but also lcalc, giac, eclib, etc. Cleaning out the sage test suite will help some, but we will inevitably spend more time on compatibility than we do now. I think it's a better use of our time though. We'll be spending time making sure it works out of the box, rather than spending time on the fallback that we have to use because it doesn't work out of the box. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/3e81f21d8b1723cf8ad6b0d632cae9393dab5c40.camel%40orlitzky.com.
