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
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
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
+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
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,
+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
At first I was very enthusiastic about this proposed policy, but after
thinking about this for a bit I'm no longer convinced this is a good idea.
First of all, the policy sets out to solve the case "where there is a
general consensus, but one person (or a few people) disagree". In my
wrote:
> >
> > On Tue, Nov 14, 2023 at 9:29 AM tobia...@gmx.de wrote:
> > >
> > > Hi everybody,
> > >
> > > I just accidentally pushed to the develop branch (instead of to a new
> branch in my fork). I'm very sorry! I leave it to the release manage
Hi everybody,
I just accidentally pushed to the develop branch (instead of to a new
branch in my fork). I'm very sorry! I leave it to the release manager to
revert/fix it to not introduce more issues.
What confuses me, however, is how this was possible in first place?! I
thought we had branch
elp, I'm available and very familiar with meson.
> On 21.10.23 05:24, tobia...@gmx.de wrote:
>
> https://github.com/sagemath/sage/pull/36489 now implements a basic meson
> setup that replaces autoconf for sage library. Given the complexities
> mentioned above, I've restricted att
https://github.com/sagemath/sage/pull/36489 now implements a basic meson
setup that replaces autoconf for sage library. Given the complexities
mentioned above, I've restricted attention to when all the dependencies are
provided via conda, which reduced the problem to something manageable.
I've now set some of the github checks as "required", so they get a small
tag in the checks list. That should take care of (2).
(Hopefully, it doesn't break Volker's workflow - it shouldn't, because he
has the rights to overwrite any branch protection rules.)
On Monday, October 16, 2023 at
Currently, the biggest problem for the type checker is that Cython is not
emitting any type annotations, so pratically all cython classes are `any`
(which is probably also the reason why the Integer return value is not
flagged). For now, one would need to generate the `pyi` stub files (using
On Wednesday, May 31, 2023 at 1:20:51 AM UTC+8 Matthias Koeppe wrote:
But the proposed vote (Tobias's PR
https://github.com/sagemath/sage/pull/35403/files) proposes to write a
strict, prescriptive interpretation into the project''s policies.
The policy should serve as a guideline for "normal
Sorry for the confusion. I forgot that there are different readings of
NEP29 and that this lead to misunderstandings before. The proposed policy
is that all python versions supported by NEP29 are also supported by sage
(this is the lower bound) and that we normally drop support for older
On Wednesday, May 31, 2023 at 12:01:04 AM UTC+8 Nils Bruin wrote:
I'd say the process for NEP 29 has now become so muddled that it's better
to start clean: Set a week (is that enough? do we need more?) for
discussion, then open a thread collecting votes *ONLY* (no comments) for
another week,
What is now the plan of action?
In my experience, the conda workflow is currently already more stable than
using sage distribution. Conda so far never failed to install a dependency
for me (but there were some minor hick-ups with the integration in sage
from time to time), while I was always
I assume in the short term, one of the most interesting application of
(Chat)GPT for sage might be the "Copilot for docs" project from github:
https://githubnext.com/projects/copilot-for-docs/ They train the model on
the official docs (/ source code?) and thus are able to provide better
Given the recent issues with the git repo at trac, should we allow pushes
to the github mirror and sync them back to trac using e.g.
https://github.com/trac-hacks/trac-github?
Would also simplify the contribution guide, since its easier to push to
github than setting up trac using ssh etc.
It would also be an idea to replace these absolute tolerance tests, i.e.
abs(x - y) < something, by a relative tests abs(x-y)/x < something. In
general, this should be more stable. Such an approach is used by pytest,
see https://docs.pytest.org/en/6.2.x/reference.html#pytest-approx. Maybe
this
Github supports non-profit organizations by giving them a free team plan.
I'm not sure about the legal status of sage, but maybe its worth trying:
https://support.github.com/contact/nonprofit.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
I think the discussion and the initial post mixes a few things that are not
really related to the question of mono- vs multi-repo. In particular, the
question of how to continue with trac is somewhat orthogonal (you can
easily have a monorepo on github or multiple trac repos).
In the end, it
Hello,
I'm using sage in an existing Jupyter notebook (that is using a 'normal'
Python backend, and *not* sage). This works great except that all the
output is plain text instead of a nice latex or image presentation
(symbolic expressions, plots, ...).
I was able to activate pretty printing
For what's worth, + 1 for migrating to github.
The interface is cleaner, it has many more features and integrations, and
is more active which could attract more contributions. There are a few
scripts/tools that allow to migrate from trac to github. But most of them
are unmaintained for a few
Just handle the PRs as would handle them normally. If these small PRs
improve something, simply merge them; if not close them saying why.
Although there are definitely people that just want to get a Tshirt (or
other swag), one should keep in mind that the idea of the hacktoberfest is
to get
ies
etc) and use dependency injection
- Test code can rely on additional libraries and other code, that doesn't
need to be shipped
On Saturday, September 5, 2020 at 7:45:53 PM UTC+2 Nils Bruin wrote:
> On Friday, September 4, 2020 at 11:18:18 AM UTC-7, tobia...@gmx.de wrote:
>&g
://trac.sagemath.org/ticket/28936
On Friday, September 4, 2020 at 7:30:53 PM UTC+2 Matthias Koeppe wrote:
> On Friday, September 4, 2020 at 7:02:27 AM UTC-7, tobia...@gmx.de wrote:
>
>> I noticed that there are a lot of doctests in the existing code that test
>> rather
Hi everybody,
I'm currently in the progress of cleaning up my code implementing
symplectic structures in sage. While doing so, I noticed that there are a
lot of doctests in the existing code that test rather elementary things.
These are often not utterly important for a user of the method,
30 matches
Mail list logo
