On Thursday, April 10, 2025 at 2:10:07 PM UTC-5 Nathan Dunfield wrote:
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 able to do that, which would >absolutely amazing, then why not wait until that's done so we can ditch >sage-the-distribution completely? Sorry, let's not try to shift the goalposts now. I didn't mean shift goalposts, I just misunderstand what you meant by the phrase "proper Python package"; the definition I'm familiar with goes farther at least on macOS/Windows. "proper Python package" in the sense "it can be built as a proper Python package", that's what I meant, sorry. Binary wheels (with self-contained binary extension modules) are a different story, and I am under the impression they are not of any use to the macOS app building. Binary wheels are just fine for the macOS app, indeed it already uses a number of them. For example, while "pillow" is a standard spkg, that version only supports a limited number of image types. So that macOS app instead uses the one off PyPI to offer more functionality. Some time ago I proposed here to have just this, allow standard packages like pillow, pytest, etc. to be pip-installable from binary wheels, and I was shouted down. Because, blah blah security blah blah no internet blah blah PyPI blah. So, let's resurrect this argument? How about an official policy to allow this? Cause this way you are, a supposedly official distributor of Sage on macOS, violating the official policy :-) But I digressed, sorry. Anyway, I'll see how hard is to build a relocateable wheel with the meson build, using uv or pip. Could be as easy as "uv build --wheel", perhaps. As far as I can see, we are at the point where macOS app can switch to using the meson build, with any Python you want. E.g. you can use the same Python as you use to package Jupyter (my understanding is that how macOS app does it). With all non-python pre-reqs in place, just run./bootstrap and pip to build sagelib, that's all. No need to worry about a dodgy custom venv, unhappy ./configure, etc. Interesting, where can I find a list of the non-python pre-reqs? Well, I recall having an argument here for a proper slotting of spkgs into sub-directories, and I was told that I just can't handle the cognitive load it takes to be a Sage dev. :-) * They don't have leading underscores in names * Among the standard spkgs (i.e. these that have "standard" in the file "type" in build/pkgs/<spkg name>), these are packages which are not having version_requirements.txt file (because these are pip-installable) Some of these packages could/should still be skipped (probably all matching py*), e.g. python3. It's all extremely logical and intuitive :-) Sorry for getting ironic. Surely Linux Sage distibutors have such lists ready. I'm planning to produce a complete range of Homebrew taps for these. There is even(stale) https://github.com/sagemath/sage/issues/29395 to handle this - but note that Macaulay2 has a number of these we can just use already. Dima We were told here that you want to build everything from source, and with this build you can do this just fine. Building from source isn't necessary per se, for example a statically-linked self-contained wheel is fine. However, nothing in the macOS app can be dynamically linked to a library in /opt/homebrew, for example. 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...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/b2631550-3391-469b-9b6d-123de153d033n%40googlegroups.com.
