[sage-devel] Re: How's tkinter on Macs?

> > Sure, but what does that mean given that nothing needs to be done? More >> specifically, what trac status should I assign? Positive review doesn't >> sound right since there's an attached patch that should *not* be applied... >> >> Put it to positive review and set the status to invalid/w

Re: [sage-devel] Re: compatibility with fink, homebrew and macports under OS X

> Homebrew tries to avoid exposing headers and libraries for packages that > are already bundled with OS X or have "alternatives" on OS X (e.g. readline > vs libedit) by installing such packages into what they call Cellars. At > least in my personal experience, this has been successful, howeve

[sage-devel] Introspection broken in Sage 6.6?

Dear all, In four different copies of Sage 6.6 on three different computers, I get the below traceback whenever I try to do introspection. I tried deleting ".sage" and ".ipython" but to no avail. I poked at it in pdb, and the "object" argument at the last stage is, as you would expect, the "b

[sage-devel] Re: Introspection broken in Sage 6.6?

> > I think it's http://trac.sagemath.org/ticket/18249 > > > . > I think you're right, thanks. Nathan -- You received this message because you are subscribed t

Re: [sage-devel] SymEngine 0.1.0 released

> > And for what it is worth, I very strongly believe we should do > everything we can to transition Sage itself over to using current > standard current approaches to development and distribution. That > means fully supporting pip, using github (instead of a custom trac and > wiki install),

[sage-devel] Re: Demote SageTeX to an optional package?

I'd be extremely hesitant to remove something that's been a standard package for over a decade unless it was causing major headaches. I could be wrong, but isn't SageTeX just a couple files totaling under 25K? The vast majority of SageMath users install it from binaries; tell them to run "make

Re: [sage-devel] Re: Demote SageTeX to an optional package?

On Monday, December 6, 2021 at 8:39:23 AM UTC-6 Michael Orlitzky wrote: > > Does "sage -i" not work either? (Is there a ticket for fixing it?) > It doesn't with the recommend macOS binaries, nor does it if you install SageMath via conda ("make: *** No rule to make target 'all-toolchain'. Stop"

[sage-devel] Re: Questions about what directory and files are safe to delete.

On Tuesday, March 8, 2022 at 9:04:22 PM UTC-6 John H Palmieri wrote: > In theory you should be able to run "make micro_release". > This mostly works, though it fails to strip some binaries which were moved in Sage 9.5. See https://trac.sagemath.org/ticket/33409 Nathan -- You received this

[sage-devel] Re: arctanh vs. artanh

Mathematica, Maple, and numpy all use "arctanh"; MATLAB uses "atanh". It's "arctanh" in the NIST Digital Library of Mathematical Functions as well: https://dlmf.nist.gov/4.37 It is the case that "ar-" prefix is the current ISO standard, and per the Wikipedia talk page the "ar-" prefix is more

[sage-devel] Re: Polling for pygments style for our future doc

I prefer sphinx with default as my second choice. I like the colors in tango, but making all the output in italic is really ugly, especially with the larger matrices in https://2505ea042169d8a179d4b1f28a0c0baeabdd421a--sagemath-tobias.netlify.app/tutorial/tour_linalg.html Best, Nathan -- You

[sage-devel] Re: Polling for sphinx background style

detoned > grayish >> original In grayish, the color for large code blocks is nearly the same as that for inline code (which is also used for methods), so some visual information is lost compared to detoned. -- You received this message because you are subscribed to the Google Groups "sage-dev

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

I think moving to GitHub makes total sense. Every other open-source math project I use regularly is on GH, and there are big network-effect benefits to being where everyone else is as others have already pointed out: easier for others to contribute, easier to get credit for contributions, easie

Re: [sage-devel] VOTE: move Sage development to Github

+1 for GitHub -- 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.goo

Re: [sage-devel] Modularization project: I. The goals

For the SnapPy project [1], modularization of Sage would very useful. Currently, we provide SnapPy as a stand-alone GUI application on Windows and macOS and as a pip-install Python module on those platforms plus Linux. When used in Sage, the SnapPy module gains extra functionality by leveragi

Re: [sage-devel] Modularization project: I. The goals

On Monday, June 12, 2023 at 2:58:18 PM UTC-4 Matthias Koeppe wrote: What parts of Sage does SnapPy use? Primarily the various rings/fields, including matrices over them and basic linear algebra. Specifically, interval arithmetic (Real/ComplexIntervalField), polynomial rings (in several varia

Re: [sage-devel] Question about reading Sage documentation

On Thursday, June 29, 2023 at 8:50:27 PM UTC-5 Marc Culler wrote: I was asking a very specific question about SageMath on Ubuntu 22.04: Are Ubuntu 22.04 users who install the sagemath-doc package able to read those (Sage 9.5) docs with Firefox? I tested this and the answer thankfully is yes.

[sage-devel] Re: -i openssl not working Mac OSX

Assuming you are using one of the recent binary packages for Sage 8.9 or 9.0, you could also use the prebuilt openssl packages available here: https://bitbucket.org/t3m/snappy/downloads/ Just download "mac_sage8.tgz" or "mac_sage9.tgz", unpack, and follow the instructions. Nathan -- You rece

[sage-devel] Re: gsl build failure on Centos 6

> > I am trying to build Sage 9.1 from source on Scientific Linux 6.10 > (=Centos 6) using gcc 7.5 provided by Conda, and am having problems getting > gsl to build: > > [gsl-2.5] > /data/keeling/a/nmd/miniconda3/envs/sage_base_lite4/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.5.0/../../../../x

Re: [sage-devel] gsl build failure on Centos 6

On Friday, July 24, 2020 at 10:43:40 AM UTC-5, Dima Pasechnik wrote: > > Can you use gsl provided by Conda? > > If you run can Sage's ./configure with conda active then it will list > "system" packages to install. > I don't think so because having conda install gsl will cause it to install conda

Re: [sage-devel] gsl build failure on Centos 6

On Friday, July 24, 2020 at 10:58:12 AM UTC-5, Isuru Fernando wrote: > > This is an issue with the openblas build. You might need > https://github.com/conda-forge/openblas-feedstock/blob/master/recipe/0002-Fix-gfortran-detection-for-ctng-based-cross-compilers.patch > > (That patch was not sent

[sage-devel] Re: Transition from jupyter notebook to jupyterlab

I use Jupyter with Sage somewhat regularly, and have tried out JupyterLab on several occasions. I use Jupyter notebooks only when making a lot of plots as otherwise I prefer an editor+REPL setup. In particular, I have not used it in any of my classes. As mentioned, JupyterLab is more like an

[sage-devel] Re: "Real Field" -> "Real Floating-point Field"

-1: I don't really care what RealField.__repr__ returns, but cast a token no vote to object to the logical next move of breaking backwards compatibility by changing the meaning of RealField and/or RR. I see the need for a "genuine real field", but it seems a lot simpler just to call it somethi

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

> > Well, seriously speaking, such drastic changes are needed sometimes, > and they demand a bump in the major version number, e.g. they can > happen in Sage 10.0. > It takes a lot of effort for a newcomer to get that RR and CC are > basically RDF and CDF on steroids, to get the mysteries of A

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

> > My perspective is partly coming as someone who has several papers that >> rely heavily on Sage computations. I've archived the code and data in a >> permanent fashion, but every backwards incompatible change Sage makes >> decreases the odds that anyone will be able to easily verify or exten

[sage-devel] Re: Sage Installation Issues on mac

Masoud, I suggest you try: https://github.com/3-manifolds/fix_mac_sage Best, Nathan -- 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...@googl

Re: [sage-devel] Re: Downgrade R to optional? See #31409.

To what extent does installing optional packages "just work" with the current binary distributions of Sage? I'm thinking of both those posted on sagemath.org as well as things not directly under our control such as the sage packages for conda, debian, gentoo, etc. My past experience has been

Re: [sage-devel] Re: Downgrade R to optional? See #31409.

this worked --- I was able to abort the build and import pyflakes --- but in the end was equivalent to building Sage from source if I hadn't stopped it. Best, Nathan On Tuesday, March 9, 2021 at 9:00:22 AM UTC-6 Nathan Dunfield wrote: > To what extent does installing optional

Re: [sage-devel] distro packaging, docbuilding and modularisation

On Wednesday, March 10, 2021 at 4:50:41 AM UTC-6 Dima wrote: > numpy does this: > https://numpy.org/devdocs/docs/howto_build_docs.html > > you can only build numpy docs after numpy is installed. > Of course, with numpy "installed" doesn't necessarily mean installed in the main site-packages, y

[sage-devel] [macOS] New beta app by Marc Culler

Dear Sage folks, Marc Culler has been working on a fully signed and notarized version of the SageMath binary for macOS, with the goal of eliminating the many problems plaguing Sage on that platform caused by Apple's gatekeeper antimalware protections. He now has posted a beta version at: http

[sage-devel] Re: [macOS] New beta app by Marc Culler

: > I tried it out! It is very slick. It resolves many issues with the current > .app.dmg that can easily scare away newcomers. > > On Sunday, April 4, 2021 at 3:47:30 PM UTC-7 Nathan Dunfield wrote: > >> Dear Sage folks, >> >> Marc Culler has been working on a full

[sage-devel] Comparing RealIntervalField elements with floats

In Sage 9.2 and earlier one has: sage: RIF(1.0) < 2.0 True sage: RIF(1.0, 3.0) < 2.0 False but in Sage 9.3beta8 (most recent docker image) such comparisons raise the below exception. --- TypeError

Re: [sage-devel] Comparing RealIntervalField elements with floats

On Apr 10, 2021, at 8:59 PM, Matthias Koeppe wrote: > Sounds like what is described in > https://wiki.sagemath.org/ReleaseTours/sage-9.3#Numerics Thanks, we will adjust SnapPy to match https://trac.sagemath.org/ticket/15114 Nathan > > On Saturday, April 10, 2021 at 6:45:09 PM

[sage-devel] Re: sage9.3 verification error for python3 on MacOS Big Sur

Try this version: https://github.com/3-manifolds/Sage_macOS/releases/tag/v1.1-beta On Monday, May 24, 2021 at 10:04:06 AM UTC-5 Udo Baumgartner wrote: > Hi, > > I installed the new sage9.3 which according to release notes supports Mac > OS Big Sur on intel machines. However, when I launch I ge

Re: [sage-devel] Safari not showing three.js plots

Ticket created at https://trac.sagemath.org/ticket/31983 On Saturday, June 12, 2021 at 4:08:26 AM UTC-5 dim...@gmail.com wrote: > On Sat, Jun 12, 2021 at 12:33 AM Nathan Dunfield > wrote: > > > > With Sage 9.3 on macOS Catalina and default browser set to Safari >

[sage-devel] Re: proposal - remove gcc, gfortran, python building/spkgs

On Thursday, June 24, 2021 at 1:16:29 PM UTC-5 Matthias Koeppe wrote: > Strong -1 on this. > Given the troubles that we have every time that a major gcc version shows > up in distributions (we still do not have GCC 11 support - > https://trac.sagemath.org/ticket/31786), and given the trouble that

[sage-devel] Re: failed in "sage -f python3" on M1 MacBook Pro with macOS Big Sur 11.1

I recommend installing either of https://github.com/3-manifolds/Sage_macOS/releases/tag/v1.0 or https://github.com/3-manifolds/Sage_macOS/releases/tag/v1.2-rc.0 which despite the description has been reported to run on M1 macs. (The 9.3 releases at the same site do not work on M1 processor

Re: [sage-devel] alternative approach to distributing sage -- jupyterlab_app

> > > Signing is a bit tricky to set up. >> >> Is that mainly due to paying the Apple Developer subscription fee? >> > > Yes, and the fact that I don't have a macOS machine with a GUI to try > things out. > I only have access to a macOS machine through SSH. > Maybe the conda or JupyterLab commun

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Friday, September 24, 2021 at 1:12:38 PM UTC-5 William Stein wrote: > I assume you are talking about the official binaries that are distributed > on Sagemath.org. Fortunately, the Sage binaries on > MacOS that are produced by the conda-forge devs are not total crap. > William, There are

Re: [sage-devel] Re: Sage no longer working in Binder

On Thursday, September 30, 2021 at 10:53:46 AM UTC-5 wrote: > My understanding is that the Sage-9.3 and Sage-9.4 binaries are broken > on a large number of machines due to an issue with how openblas was > built. You probably have to use a sage-9.2 docker container, or wait > for sage 9.5 to com

[sage-devel] Re: How to modularize for fun and profit, II: MONOREPO vs. MULTIREPO

On Sunday, October 10, 2021 at 7:17:33 PM UTC-5 Matthias Koeppe wrote: > *Recommendation:* Keep MONOREPO for all distributions that fill the > sage.PAC.KAGE.MODULE namespace (= distribution packages named *sagemath-... > *-- according to my recommendation in part I). > > *Recommendation: *For d

[sage-devel] Re: documentation of SageMath (Python) packages

Vincent, Imagine I have a Python module, typically hosted on PyPI and depending > on SageMath, that provides documentation in some form (e.g. a pdf file, > a sphinx repo, etc). > > 1) When a user performs `sage -pip install X`, should the documentation > be compiled and installed? > I

[sage-devel] Python 3: adding object to a category

Taking Frédéric's advice to heart, I have begun porting SnapPy to Sage+Python3. (We have supported Python 3 outside of Sage for a few years now.) Right now, I am having difficulty with how to register something as a field. Below is the minimal (non) working example: if you run it with Python

[sage-devel] Re: Python 3: adding object to a category

On Sunday, February 3, 2019 at 2:22:33 AM UTC-6, Frédéric Chapoton wrote: > > git grep "@add_metaclass" src/sage > > will give you plenty of examples on how to add metaclasses in a py3 > compatible way > Frédéric, Thanks for the pointer, following those examples solved my problem! Nathan --

[sage-devel] Re: Python 3: adding object to a category

On Sunday, February 3, 2019 at 6:39:42 PM UTC-6, Simon King wrote: > > > Thanks for the pointer, following those examples solved my problem! > > Note, however, that it only adresses the question how to use a metaclass > in py3. It does not address the question how to use Sage's category > framew

[sage-devel] Python 3: gap interface issue

On Sage 8.6 with Python 2, the following command produces the expected result (namely, a sage.interfaces.gap.GapElement): sage: gap('0') 0 whereas in Sage 8.6 with Python 3 I get the following error: sage: gap('0') --- File

[sage-devel] Re: Python 3: gap interface issue

On Sunday, February 3, 2019 at 7:23:52 PM UTC-6, Simon King wrote: > > Hi Nathan, > > On 2019-02-04, Nathan Dunfield > > wrote: > > On Sage 8.6 with Python 2, the following command produces the expected > > result (namely, a sage.interfaces.gap.GapElement):

Re: [sage-devel] Re: Python 3: gap interface issue

On Sunday, February 3, 2019 at 10:31:21 PM UTC-6, Dima Pasechnik wrote: > > I don't know what exactly is wrong with that docker container, but > certainly GAP workspace might not be present if you never ran GAP via > pexpect. It is created and rotated on the fly. > Does > > sage: gap_console()

Re: [sage-devel] Re: Python 3: gap interface issue

On Monday, February 4, 2019 at 8:12:02 AM UTC-6, Nathan Dunfield wrote: > > On Sunday, February 3, 2019 at 10:31:21 PM UTC-6, Dima Pasechnik wrote: >> >> I don't know what exactly is wrong with that docker container, but >> certainly GAP workspace might not be pre

[sage-devel] PolyRings over NumberFields: odd UserWarning

Dear Sage folks, For a number field K whose defining polynomial has a non-integral rational coefficient, factoring a polynomial with coefficients in K sometimes results in the following UserWarning: SageMath version 8.8.beta1, Release Date: 2019-04-07 sage: K. = NumberField(x^2 - 1/2) sage: R.

[sage-devel] Re: PolyRings over NumberFields: odd UserWarning

On Saturday, May 4, 2019 at 10:45:56 AM UTC-5, Nathan Dunfield wrote: > > Dear Sage folks, > > For a number field K whose defining polynomial has a non-integral rational > coefficient, factoring a polynomial with coefficients in K sometimes > results in the following UserWar

[sage-devel] Re: Possible to use current Sage version in travis-ci?

On Wednesday, July 31, 2019 at 4:33:21 PM UTC-5, Simon King wrote: > > Question: Is it (reasonably) possible to use a sage beta version in > travis-ci? How? > Docker images with beta versions of Sage are available, so just change the https://hub.docker.com/r/sagemath/sagemath/tags requested i

[sage-devel] Re: Possible to use current Sage version in travis-ci?

On Wednesday, July 31, 2019 at 4:33:21 PM UTC-5, Simon King wrote: > > Question: Is it (reasonably) possible to use a sage beta version in > travis-ci? How? > Docker images with beta versions of Sage are available: https://hub.docker.com/r/sagemath/sagemath/tags so just change the requested im

Re: [sage-devel] drop python2 compatibility in 9.1 ?

On Friday, January 10, 2020 at 8:11:43 AM UTC-8, William wrote: > > The main person that has valid reason to want longer support for python2 >> is William. >> As he mentions, he has paying customers. >> > > I am 100% satisfied for my use case with cocalc by just keeping a copy of > sage-8.9 avail

[sage-devel] Re: Poll: make giacpy_sage a standard package

On Monday, February 3, 2020 at 4:52:44 PM UTC-6, Samuel Lelievre wrote: > > Please vote for making giacpy_sage a standard package. > +1 The "giacpy_sage" optional package is one I always install when I build Sage and it has been robust in my experience. As others have said, given that giac its

[sage-devel] Re: sagemath 9.0 for MacOS is not linked with SSL

Unfortunately, no recent SageMath binary for macOS comes with a working SSL lib. Two fixes: 1) Download "mac_sage9.tgz" from https://bitbucket.org/t3m/snappy/downloads/ unpack, and follow the instructions. 2) Assuming you have the XCode command line tools installed, the following usually wo

[sage-devel] Re: Get Python3 to build its ssl and tkinter modules on macOS

On Sunday, March 29, 2020 at 5:09:26 PM UTC-5, Samuel Lelievre wrote: > > Dear sage-devel, > > on macOS, is there a recommendation on how to > get Python3 to build its ssl and tkinter modules > when building Sage from source? > > I'm using macOS 10.14.6 Mojave. > This is not quite answering your

[sage-devel] Re: sage_sample

> * is there any example of a package using Travis CI testing on sage9 and > maybe with docker that I could use as an example? > Yes, we do that for SnapPy. The relevant files are here: https://github.com/3-manifolds/SnapPy/blob/master/.travis.yml https://github.com/3-manifolds/SnapPy/blob/m

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

Dima mentioned "tox" [1] as an example of a "standard" package that would benefit from being switched to a "pip" package. The "tox" package is pure python, so could also made a "wheel" package, which are already allowed for standard package, for example [2]. I'm having difficultly understandin

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Friday, February 16, 2024 at 11:17:37 PM UTC-6 Matthias Koeppe wrote: If one does not care about the use case without internet access, then it's just the following: - Pinning, as you mentioned (see also https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ above, where I discu

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Saturday, February 17, 2024 at 1:13:33 PM UTC-6 Dima Pasechnik wrote: My proposal is in fact aimed at reducing the number of pinned Sage dependecies, drastically. Because most of them are either dependencies of Jupyterlab, or of Sphinx, or of Python build system, and none of the them should

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Sunday, February 18, 2024 at 6:26:28 AM UTC-6 Dima Pasechnik wrote: I cannot imagine CI breaking down by, say, pytest. I can definitely see that happening, and indeed it seems to have done so for other projects: https://github.com/pytest-dev/pytest/issues/9765 https://github.com/pytest-dev/

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Sunday, February 18, 2024 at 12:14:58 PM UTC-6 Dima Pasechnik wrote: Reading: https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-source-types The wheel you talk about is just another packaging of a source package, isn't it? No. Well, I might have used inco

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Monday, February 19, 2024 at 3:08:54 PM UTC-6 John H Palmieri wrote, responding to Dima: You said: "The difference between wheel packages vs pip packages is that the latter don't require pre-fetched wheels, and absence of the need for package (micro)management." The implication is that chang

[sage-devel] Re: VOTE: disputed PRs

+1 -- 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/m

[sage-devel] Re: VOTE: Use "CI Fix" label for merging into continuous integration runs

+1 -- 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/m

[sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

+1: Using the PyPA standard build tools is a good move. On Tuesday, April 9, 2024 at 10:44:36 PM UTC-5 Matthias Koeppe wrote: > We added python_build as an optional "pip" package (see > https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types > for > the terminolo

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Saturday, April 20, 2024 at 5:01:04 PM UTC-5 kcrisman wrote: Can someone who is not Dima or Matthias explain to us how it is possible that they both are claiming to represent the normal Python way of doing things? There have been numerous statements by both of them about this, which makes i

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Wednesday, April 24, 2024 at 2:26:37 PM UTC-5 Oscar Benjamin wrote: Thanks Marc. This seems like a good example of a useful part of Sage that can be extracted to something much smaller than Sage. Presumably though a hypothetical person who wants CyPari2 but not all of Sage can already just

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Wednesday, April 24, 2024 at 4:25:41 PM UTC-5 Dima Pasechnik wrote: On Wed, Apr 24, 2024 at 9:29 PM Nathan Dunfield wrote: > On a related note, the reason that CyPari2 and CyPari are still separate relates to what Marc mentioned earlier about tension between two models of installing softw

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote: Yes, native Windows would clearly be a very important target. As a data point, downloads of our stand-alone SnapPy app, which is about as high level pure math as it gets, are 60% higher for Windows than macOS. In anothe

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Thursday, April 25, 2024 at 2:17:31 AM UTC-5 Martin R wrote: I agree that my terminology is not good. I tried to make a distinction between research involving math and the - to me unknown - rest. I find it hard to imagine that any mathematician would bother installing anything else but all

[sage-devel] Re: Proposal (redo): Make pytest, pytest_mock, pytest_xdist + dependencies standard packages

The six packages proposed for addition are all pure-Python and collectively take up 4M installed (about a 450K download); for scale, I think a full Sage installation is about 3G (1.25G download). They all seem to be well-maintained, and common enough that all are available on conda-forge. Usi

[sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Friday, May 31, 2024 at 11:38:34 AM UTC-5 Dima Pasechnik wrote: Before looking at https://groups.google.com/g/sage-devel/c/lPLoA7zaoyg/m/dGE1B1jQEQAJ we should look at this proposal again, as pytest is a very suitable candidate for the kinds of packages (standard pip packages) proposed here.

[sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Thursday, June 6, 2024 at 5:56:15 AM UTC-5 Dima Pasechnik wrote: Yet, pytest, a pip package, is installed and used rather regularly in Sage, and nobody gets hurt. It is found to be safe to install this particular package this way ("pip install pytest" does not affect anything in the Sage v

[sage-devel] Re: Demote brial (= polybori) from standard to experimental

This makes sense to me. Nathan On Sunday, October 1, 2023 at 2:29:55 PM UTC-5 Matthias Koeppe wrote: I propose to demote this package to experimental. - It has been declared dead at least once - https://martinralbrecht.wordpress.com/2015/06/13/polybori-is-dead-it-needs-your-help/ - It has no u

[sage-devel] Re: Proposal: Policy for standard packages from binary wheels

This proposal makes sense to me. Something like this is necessary for us to upgrade Jupyter since it depends on rdps-py which needs Rust to build, and this approach preserves the other features of current standard packages: the version is pinned (including checksums on the binary wheels) and a

Re: [sage-devel] Re: Proposal: Policy for standard packages from binary wheels

tion? Is it forbidden to > mention my proposals on sage-develop nowadays? > > On Tue, Aug 6, 2024 at 1:49 PM Nathan Dunfield > wrote: > > > > This proposal makes sense to me. Something like this is necessary for us > to upgrade Jupyter since it depends on rdps-py which

Re: [sage-devel] Proposal: Policy for standard packages from binary wheels

On Thursday, August 8, 2024 at 7:57:12 AM UTC-5 Marc Culler wrote: I think it would be possible to use a single spkg for all of the additional binary wheels, where the main content of that spkg is a requirements.txt file listing versions and hashes. Yes, that is approach Matthias implemented

[sage-devel] Re: (I’m failing to build a working binary) Please provide a snapcraft package/container as now all but one Linux distributions no longer package Sagemath.

I recommend you install SageMath via Conda: https://doc.sagemath.org/html/en/installation/conda.html#install-from-conda-forge In my experience, this method "just works" even on seriously old and cranky Linux distros. Best, Nathan On Thursday, August 22, 2024 at 12:32:08 PM UTC-5 lael.c...@gma

[sage-devel] Re: Proposal to allow downloads during build of optional packages

On Tuesday, December 31, 2024 at 8:04:22 PM UTC-6 Kwankyu Lee wrote: To be clear, note that we have two types of packages: standard and optional. Standard packages are by definition those packages installed by default. See https://doc-release--sagemath.netlify.app/html/en/developer/packaging#pa

Re: [sage-devel] PROPOSAL: remove python3 spkg from Sage

Dima, I looked through the logs, do you agree the following is a rough summary of the issue in this case? The user building Sage from source uses a package manager that installs software in /opt/homebrew/. They had some components of Sage installed in /opt/homebrew but fewer than we recommend

Re: [sage-devel] PROPOSAL: remove python3 spkg from Sage

On Thursday, April 10, 2025 at 12:07:03 AM UTC-5 Dima wrote: > Probably not on the build system. But the app needs to work on *any* system. > >> Are you worried that sage would have trouble recognizing the python build as valid for its purposes? > No. Because sagelib (with meson build) is al

Re: [sage-devel] PROPOSAL: remove python3 spkg from Sage

On Wednesday, April 9, 2025 at 2:58:51 PM UTC-5 Trevor Karn wrote: At the same time, the concession that python3.spkg *can* still provide python if really wanted helps Marc see that the MacOS app build is taken seriously. I would expect it's a major delivery platform of sagemath functionality t

Re: [sage-devel] PROPOSAL: remove python3 spkg from Sage

On Thursday, April 10, 2025 at 9:37:09 AM UTC-5 Dima wrote: On 10 April 2025 07:45:09 GMT-05:00, I wrote: >To me, a "proper Python package" is something I can install with >"random-python -m pip install blah" that pulls a binary wheel off PyPI that >just works. If we're getting close to being

Re: [sage-devel] PROPOSAL: remove python3 spkg from Sage

1) Having sagemath detect python version requirements and build its own if not acceptable version is found leads to increased support requests. [...] It seems to me that for 1) it isn't so important if python occurs as an spkg or not -- the main issue there would be resolved if the build pro

Re: [sage-devel] PROPOSAL: remove python3 spkg from Sage

On Monday, April 7, 2025 at 1:19:45 AM UTC-5 Dima wrote: Homebrew, uv, etc provide single-arch Python3 just fine. I believe that Homebrew wouldn't work because of the issue with rpaths that Marc hints at earlier in his message -- in particular the paths are baked in as /opt/homebrew/* and will

[sage-devel] Re: dropping numpy 1 support?

One possible disadvantage is that Ubuntu 24.04, one of the most common distros, uses numpy 1.26 [1]. The current SageMath package for Debian/Ubuntu is 9.5, so dropping support for numpy 1 would make it impossible to release an updated the Debian/Ubuntu SageMath package. However, I don't know

<    1   2