+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
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 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
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
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
> 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
-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
"
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
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
> 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
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
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
@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
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
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
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
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
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
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
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 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
+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
> 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
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
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
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
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
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
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
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
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
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
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
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:
>
>
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
38 matches
Mail list logo
