1:35:36 AM UTC+8 Vincent Macri wrote:
> On 2025-09-03 6:01 a.m., 'tobia...@gmx.de' via sage-devel wrote:
> > I second that "needs review" and "needs work" are mostly obsolete and
> > should be better handled by native github tools. Those labels were
>
I second that "needs review" and "needs work" are mostly obsolete and
should be better handled by native github tools. Those labels were
introduced when migrating to github to not change the workflow too much
from the good old trac days. Besides the automatic transition "needs work"
-> "needs r
cessful.
On Friday, August 29, 2025 at 3:50:30 AM UTC+8 Vincent Macri wrote:
> On 2025-08-27 6:42 p.m., 'tobia...@gmx.de' via sage-devel wrote:
>
> I don't think tests need to be disabled, but rather the CI should not
>
> report a PR as failing if the same failure occ
I don't think tests need to be disabled, but rather the CI should not
report a PR as failing if the same failure occurs on develop. So still
run the failing tests, but don't report the workflow as failing if the
same test fails on develop. I think we already have something like this
for the f
To slightly expand on the above: We do have tests with fixed (build.yml)
and with variable random seed (ci-meson.yml). But even with a fixed seed
you do get sometimes, often non-reproducible, failures. Some of these
issues are known for a long time (eg
https://github.com/sagemath/sage/issues/29
The biggest issue with the reliability of the CI is a deep design decision
in the way the tests are setup. Many doctests have an inherent random
element, and this is mostly on purpose to increase the surface of code
paths that are tested and thereby discover new bugs. The disadvantage is
that u
Thanks Marc and everyone involved in this work!
I second that it should be mentioned in the install section. And, to keep
the appimage up-to-date, the build scripts and CI should be perhaps
included in the main repo as well (similar to the existing docker build).
On Tuesday, August 19, 2025 at
Thanks for the explanation. In https://github.com/sagemath/sage/pull/40609,
I've tried to fix the small bugs in the docs that you pointed out. However,
> If I use the next button (say the Fedora part) the $ character is also
copied and the copied text gives an error in the terminal because of th
Thanks a lot for giving this a try!
Before starting, if one copies the instructions in html, it is OK when in
the rst the instruction
is written in the file but $ is typed when it is an instruction
following .. literalinclude
I'm not sure I follow completely. It works correctly if you copy
Looks like your conda env is missing some dependencies. I suggest you
follow
https://doc-develop--sagemath.netlify.app/html/en/developer/walkthrough
On Thursday, June 26, 2025 at 5:40:49 AM UTC+2 janmenjay...@gmail.com wrote:
> Hello,
> I ran the following command as a part of an installation e
What issues did you experience with the meson build? The notebook
functionality should still work as usual via `sage -n`.
On Monday, May 19, 2025 at 11:56:58 PM UTC+8 chris wuthrich wrote:
The problem is still present with beta4.
(And with the meson approach I didn't get very far either, no not
You have to (pip)install `meson`. Not sure what's the sage-the-distro way
of doing this (or why meson is not automatically installed in the venv).
Or, preferably, after https://github.com/sagemath/sage/pull/39262 you can
just run `uv run tools/update-meson.py`.
On Friday, May 16, 2025 at 5:05:2
Yes the meson files need to be changed whenever you add or remove python or
cython files. Either run 'tools/update-meson.py' locally or apply the
changes suggested in the above output manually.
On Thursday, May 15, 2025 at 11:51:16 PM UTC+8 axio...@yahoo.de wrote:
> The patchbot reports the fo
You can try https://github.com/sagemath/sage/pull/40071 by installing all
system packages and uv, and then run:
uv pip install meson-python "cysignals >=1.11.2, != 1.12.0" "cython >=3.0,
!= 3.0.3, != 3.1.0" "gmpy2 ~=2.1.b999" memory_allocator "numpy >=1.25"
setuptools jinja2
uv pip install --n
That's probably due to a recent clang. Should be fixed by
https://github.com/sagemath/sage/pull/39526 in the develop branch.
On Thursday, May 1, 2025 at 11:22:41 PM UTC+8 dim...@gmail.com wrote:
> It's hard to tell, but does your environment use Apple's toolchain, or
> Conda toolchain.
> Could
I'd already removed this in a merged PR
https://github.com/sagemath/sage/pull/39031. No idea why this file is now
back. Feel free to open another PR deleting it again ;-)
On Wednesday, April 30, 2025 at 8:06:39 PM UTC+8 David Coudert wrote:
> I see that a file named Pipfile is generated when bu
The docs for conda are outdated (there is already a PR in the pipeline
fixing this). Please use meson following
https://doc.sagemath.org/html/en/installation/meson.html
On Friday, April 25, 2025 at 5:46:15 AM UTC+8 dim...@gmail.com wrote:
> On Thu, Apr 24, 2025 at 4:35 PM Nils Bruin wrote:
>
>
On Saturday, April 19, 2025 at 7:12:16 AM UTC+8 Nils Bruin wrote:
So a middle ground would be to offer a security blanket during the
transition: change the default behaviour of the python package for now to
NOT build, but as a transition measure offer a configuration flag that
restores the abil
Marc, what is your opinion about replacing "building from source" in the
Python spkg by "installing the prebuild pythons from
astral/python-build-standalone"? Would this work for the MacOS app; and if
not why?
Other popular projects, like anki and influxdb, seem to use these builds
for their e
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?
https://github.com/sagemath/sage/blob/871ba9daed15374
There is no real roadmap. The low-hanging fruit is to replace all `pip
install` in CI with uv to make use of the lock file mechanism.
Moreover, I could imagine the following aim for installing sage from source
(without using conda):
1) Install all system packages
2) Run `uv sync` to build (and i
What are good criteria for evaluating different ways to install Python?
-
Reliability
-
Installation speed
-
Disk space used after installation
-
Ease of use for end users
-
Suitability for distributions
-
Suitability for the macO
E.g., there are many packages in Sage that use
> autotools -- does this mean that all of them have a non-autotools
> build process as well now?
>
> Thanks for whatever quick context you can easily provide,
>
> William
>
> On Thu, Apr 3, 2025 at 3:47 AM 'tobia...@gmx.
Dear developers,
I am excited to announce that SageMath now supports the Meson build system!
This modern alternative to Autotools brings several key advantages:
- *Faster Builds* – Meson significantly reduces configuration and
compilation time due to better parallelism (some benchmark
Sounds like a good idea. Installing a specific version of Python nowadays
is easy enough and there a few tools that make this experience as smooth as
possible. For example, uv uses prebuild pythons for many OS to speed up the
installation and to reduce the risk of build errors (see
https://gith
I couldn't find a way to register to this wiki, so could someone please
update the page with the following info? Thanks! (Maybe for next time use
https://github.com/sagemath/sage/wiki)
Project: Lie group actions on manifolds
Mentor: Tobias Diez, Erik?
Area: Differential Geometry
Skills: Knowl
> I suggest to make the checks information only; the check report failed
step, but the check itself passes always.
I don't think this is a good idea. If some tests fail randomly, then that's
an issue with the test and not with the "engine". Just fix the test or, if
that's too much work for now
+1 on disabling all doctests that randomly fail.
https://github.com/sagemath/sage/pull/39100 might be helpful in discovering
these flaky tests.
Do you also want to disable CI workflows that sometimes fail for intrinsic
reasons? For example, the Build & Test workflow often fails to push the
tem
As with many such choices, the decision is subjective. However, I highly
recommend VS Code. It starts as a lightweight editor but can become quite
powerful as you explore its features further.
For the workshop, you might find Codespaces particularly useful. This
feature allows you to edit an
ignals` works in the conda python. I guess
> because
> it's installed in `$CONDA_PREFIX/lib/python3.11/site-packages`.
>
> On 1/1/25 7:29 PM, 'tobia...@gmx.de' via sage-devel wrote:
> > Can you please also post the output of
> /home/grhkm/git/sage/build/cp31
Can you please also post the output of
/home/grhkm/git/sage/build/cp311/meson-logs
Does `import cysignals.signals` from python in the activated conda env work?
On Wednesday, January 1, 2025 at 6:08:04 PM UTC+8 grh...@gmail.com wrote:
> I am trying to use the `meson` build method instead of cond
I don't understand what you are saying. When you say "works on Windows" do
you mean that the build works? I am certain that sig_on and sig_off do not
work on Windows if you have not added any Windows-specific signal handling.
Yes, the build works on Windows as well as all tests are passing
The new version of cysignals, released just a couple of hours ago, now
builds using Meson and works fine on Windows. Thanks Dima and Frédéric for
the quick reviews and the new release! At the moment, we don't provide
wheels for windows but this can be added if it's a hard requirement for you
or
I'm very happy to see improvements to the Windows installation. I don't
have the time right now to try your powershell script, but it looks like a
nice walk-through for not-so-technical users. Do you want to add it to the
docs?
Another alternative would be to import the docker image as a WSL
d
Currently, when you try to package sage on a new distro, you need to have
all dependencies installed before you can even explore building sage. The
modularization effort could be helpful in this regard, because it enables a
more incremental approach where you first package a smaller subset of th
Thanks, that's helpful!
On Monday, September 23, 2024 at 8:34:26 PM UTC+8 Michael Orlitzky wrote:
> On Sun, 2024-09-22 at 20:05 -0700, 'tobia...@gmx.de' via sage-devel
> wrote:
> > Michael, to make things short: The discussion is around these changes to
&g
Michael, to make things short: The discussion is around these changes to
the `pyproject.toml` file
https://github.com/sagemath/sage/pull/38227/files#diff-0acbedc0b174ebec342997fdca9442a5486917ab04644da866213e97d2543604
which he claims harmonize the constraints with scipy (although scipy
actual
The PR does not include any explanation as to why the changes to
pyproject.toml are necessary, nor does it provide any guidance on how to
test them. I used the standard configure process (now also with the
system-site-packages switch) followed by make, both with and without these
changes, an
Moreover, there is actually a very simple way to specify a different
constraint for sage-the-distro: just remove the auto-gen of the
version-requirements file, and provide an own one for sage-the-distro.
That way was discussed in
https://github.com/sagemath/sage/pull/37902#discussion_r174489
@Kwankyu, replying here to your comments.
The cython constraint in scipy is for build-time. Sagelib only cares about
the fact that scipy is installed in the same venv, not how you install or
build it. In fact, pip uses build isolation by default, or you may install
scipy using the prebuilt whee
Why would one want to specify a more narrow version range? That would only
impose unnecessary constraints on downstream packaging efforts.
Another example: https://github.com/sagemath/sage/pull/38556
On Thursday, August 22, 2024 at 8:32:02 PM UTC+2 Matthias Koeppe wrote:
> On Thursday, August 2
People interested in maintaining sagelib should only care about the version
constraint in the pyproject.toml file (e.g. if they decide that a new
feature of numpy is needed, then the version constraint of numpy should be
changed accordingly). People interested in maintaining sage-the-distro
sho
> the version constraints of the packages that happen to be build
dependencies of the Sage library (enumerated in
https://github.com/sagemath/sage/blob/develop/bootstrap#L36) are set in
https://github.com/sagemath/sage/blob/develop/src/pyproject.toml#L3
Right (adhering to the standard of moder
I've now set https://github.com/sagemath/sage/pull/37998 back to "need
work" for the following reasons:
- Needs to be tested on all 6 os/python version combinations
- Updates of the conda lock files should never require additions to the
"known bugs" exclusions. If a certain version upgrade result
In reply to the comment
(https://github.com/sagemath/sage/pull/36676#issuecomment-2067371677)
>> My fear would be that at some point there is a request not to use
symbolics in some module, because Lisp is hard to install on some system.
>That should not happen. Modularization is downstream to
-1
The usage of "setup.py sdist" or "setup.py bdist_wheel" only happens in
certain edge cases (e.g. the almost un-documented `--enable-wheels` option)
and in these cases it is no problem to require developers to run `pip
install build` beforehand. So these last remaining instances of calling
"
> 4. Please vote -1 on https://github.com/sagemath/sage/pull/36580,
https://github.com/sagemath/sage/pull/36753, and
https://github.com/sagemath/sage/pull/37138, which attempt to obstruct the
modularization project and the mechanism for the distribution on PyPI.
Please refrain from such unfoun
I think Martin raises important points and agree that 0-4 should be added
to the code of conduct (more in spirit than in this particular formulation;
for example, I like the proposed reformulations of David). Point 5 is
important as well, but I would say it's enough to spell out the rules
gover
Just move "usage 2" to a new label. Would be more intuitive and explicit in
my opinion.
On Monday, February 26, 2024 at 1:25:34 PM UTC+8 Kwankyu Lee wrote:
> Hi
>
> "blocker" label is overloaded too much. It is used for
>
> usage 1: PRs that should be merged to the next release
> usage 2: PRs th
+1 for the one-line change of the type from "optional" to "standard". -1 on
everything ("standard pip" or "standard wheel") that involves an
unnecessary version constraint and an explicit declaration of the runtime
dependencies.
On Saturday, February 17, 2024 at 4:51:45 PM UTC+8 Dima Pasechni
This discussion about the need to fix the version of pytest *and its
runtime dependencies* is almost comical. We are installing and running
pytest successfully since 3 years without any version requirement via pip
in ci and experienced zero issues. We are also not alone in that. For
example, sc
+1 for both proposals.
Via "pip download" (https://pip.pypa.io/en/stable/cli/pip_download/) it is
easy to resolve and download all pip packages on a system with internet
connection, and then later on the target system install it without the need
for internet.
On Tuesday, February 13, 2024 at 9
52 matches
Mail list logo
