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
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
