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
pe wrote:
> On Friday, September 6, 2024 at 1:43:32 AM UTC-7 tobia...@gmx.de wrote:
>
>
> I've set the PR back to needs work since the version constraints in
> pyproject.toml for cython and numpy are not needed in my testing,
> definitely not for sage-the-lib but apparently
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
tting in the way of sagelib.
> On Sunday, August 25, 2024 at 6:52:40 AM UTC+1 Matthias Koeppe wrote:
>
>> On Friday, August 23, 2024 at 1:21:47 PM UTC-7 tobia...@gmx.de wrote:
>>
>> Why would one want to specify a more narrow version range?
>>
>>
>> It'
ust 22, 2024 at 2:41:57 AM UTC-7 tobia...@gmx.de wrote:
>
> 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 shoul
the corresponding version constraint file is generated).
On Thursday, August 22, 2024 at 12:35:57 AM UTC+2 Nils Bruin wrote:
On Wednesday 21 August 2024 at 15:29:05 UTC-7 Matthias Koeppe wrote:
On Wednesday, August 21, 2024 at 2:12:30 PM UTC-7 tobia...@gmx.de wrote:
> the version constraints
> 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
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
experienc
ima Pasechnik 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 t
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
you need help, 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
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.
Thus
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 12:0
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
so
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
versio
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 af
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
results
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. (Als
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 u
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 is
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 w
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 y
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 new
es (web resources, libraries
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..
https://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 e
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, but
39 matches
Mail list logo