On 1 June 2024 15:50:56 CEST, Nathan Dunfield wrote:
>On Friday, May 31, 2024 at 11:38:34 AM UTC-5 Dima Pasechnik wrote:
>
>Before looking at
>https://groups.google.com/g/sage-devel/c/lPLoA7zaoyg/m/dGE1B1jQEQAJ
>we should look at this proposal again, as pytest is a very suitable
>candidate
On Tue, Feb 20, 2024 at 1:57 AM Nathan Dunfield
wrote:
> On Monday, February 19, 2024 at 3:08:54 PM UTC-6 John H Palmieri wrote,
> responding to Dima:
>
> You said: "The difference between wheel packages vs pip packages is that
> the latter don't require pre-fetched wheels, and absence of the
Blocking on GitHub, I presume, is due to disagreements on a number of topics,
including the topic discussed in this thread. So it's related to the topic, and
personal only as it was done by a person, not by an AI.
On 27 February 2024 22:17:50 GMT, John H Palmieri
wrote:
>That's called
That's called "whataboutism". Invoking what you consider inappropriate
behavior by others is not relevant. Please stay on topic, and please follow
Sage's code of conduct in your posts.
On Tuesday, February 27, 2024 at 1:01:25 PM UTC-8 Dima Pasechnik wrote:
>
>
> On 27 February 2024 20:44:50
On 27 February 2024 20:44:50 GMT, John H Palmieri
wrote:
>Sentences like "At the moment you are actively breaking down the precious
>project fabric, all in the name of you having your way" are personal
>attacks. Please stop.
Blocking on GitHub members of the project is not a personal
On 27 February 2024 20:21:26 GMT, Nils Bruin wrote:
>On Tuesday 27 February 2024 at 10:50:55 UTC-8 John H Palmieri wrote:
>
>
>As Nathan points out, this will likely lead to instability. Someone will
>upgrade some component, and most of the time that will be fine, but
>occasionally it will
Sentences like "At the moment you are actively breaking down the precious
project fabric, all in the name of you having your way" are personal
attacks. Please stop.
On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote:
>
>
> On 27 February 2024 19:37:31 GMT, Matthias Koeppe
On 27 February 2024 19:37:31 GMT, Matthias Koeppe
wrote:
>On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri wrote:
>
>A pretty safe second choice would be to have "make download" also download
>the relevant files for pip installation and tell pip where to find them. If
>we
On 27 February 2024 18:50:55 GMT, John H Palmieri
wrote:
>Regarding the proposal to allow standard packages to be pip packages, no
>one really knows how much people rely on the all-in-one tarball that we
>currently distribute. No one really knows how often the "make download"
>option is
On 20 February 2024 22:44:02 GMT, Matthias Koeppe
wrote:
>On Tuesday, February 20, 2024 at 12:45:25 PM UTC-8 Dima Pasechnik wrote:
>
>On Tue, Feb 20, 2024 at 8:13 PM Matthias Koeppe
>wrote:
>
>I have been doing the vast majority of this maintenance work in the past 4
>years, and I have
On Tuesday, February 20, 2024 at 12:45:25 PM UTC-8 Dima Pasechnik wrote:
On Tue, Feb 20, 2024 at 8:13 PM Matthias Koeppe
wrote:
I have been doing the vast majority of this maintenance work in the past 4
years, and I have been improving the tooling to reduce the workload
associated with it --
On Tue, Feb 20, 2024 at 8:13 PM Matthias Koeppe
wrote:
> On Tuesday, February 20, 2024 at 11:43:07 AM UTC-8 Dima Pasechnik wrote:
>
> On 20 February 2024 17:28:31 GMT, Matthias Koeppe
> wrote:
> >On Tuesday, February 20, 2024 at 1:43:27 AM UTC-8 Dima Pasechnik wrote:
> >The number of
On Tuesday, February 20, 2024 at 11:43:07 AM UTC-8 Dima Pasechnik wrote:
On 20 February 2024 17:28:31 GMT, Matthias Koeppe
wrote:
>On Tuesday, February 20, 2024 at 1:43:27 AM UTC-8 Dima Pasechnik wrote:
>The number of dependencies has grown to the point it has gotten too hard
to
>maintain,
On 20 February 2024 17:28:31 GMT, Matthias Koeppe
wrote:
>On Tuesday, February 20, 2024 at 1:43:27 AM UTC-8 Dima Pasechnik wrote:
>
>The number of dependencies has grown to the point it has gotten too hard to
>maintain,
>
>
>No. It's easier than it has ever been in the past because of our
On Tuesday, February 20, 2024 at 1:43:27 AM UTC-8 Dima Pasechnik wrote:
The number of dependencies has grown to the point it has gotten too hard to
maintain,
No. It's easier than it has ever been in the past because of our improved
tooling.
especially if one aims to support as many Python
On 20 February 2024 01:57:40 GMT, Nathan Dunfield wrote:
>On Monday, February 19, 2024 at 3:08:54 PM UTC-6 John H Palmieri wrote,
>responding to Dima:
>
>You said: "The difference between wheel packages vs pip packages is that
>the latter don't require pre-fetched wheels, and absence of the
On Monday, February 19, 2024 at 3:08:54 PM UTC-6 John H Palmieri wrote,
responding to Dima:
You said: "The difference between wheel packages vs pip packages is that
the latter don't require pre-fetched wheels, and absence of the need for
package (micro)management." The implication is that
On Monday, February 19, 2024 at 2:41:11 PM UTC-8 Dima Pasechnik wrote:
On Mon, Feb 19, 2024 at 10:29 PM Matthias Koeppe
wrote:
An option to "./configure" could work too, except that the "bootstrap"
phase already downloads the "configure" tarball into that directory.
an option to ./bootstrap
You're right, plus I was confusing "./bootstrap -d" (which is run by "make
configure") with "./bootstrap -D" which forces the download.
On Monday, February 19, 2024 at 3:17:11 PM UTC-8 Matthias Koeppe wrote:
> On Monday, February 19, 2024 at 3:09:55 PM UTC-8 John H Palmieri wrote:
>
> By the
On Monday, February 19, 2024 at 3:09:55 PM UTC-8 John H Palmieri wrote:
By the way, I just cloned the Sage repo and ran "make configure", which
runs `./bootstrap`. The upstream directory is empty after that.
You probably have autoconf/automake/... installed. In this case, it just
uses them to
If we keep a "configure" tarball in each separate Sage installation but
they share the rest of "upstream", then we save a lot of space and a lot of
downloading. A workflow like
% make configure
% configure --with-lots-of-options
% make
would be familiar and unchanged from the status quo when
On Mon, Feb 19, 2024 at 10:29 PM Matthias Koeppe
wrote:
> An option to "./configure" could work too, except that the "bootstrap"
> phase already downloads the "configure" tarball into that directory.
an option to ./bootstrap then would be logical
>
> Another possible direction: I've been
On 19 February 2024 21:08:54 GMT, John H Palmieri
wrote:
>
>
>On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote:
>
>On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote:
>
>This (A and B below) has the advantage of being quite explicit. The
>original proposal
>
>1)
On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote:
On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote:
If we convert (according to (1)) to pip packages, those still need to be
downloaded, and while they may not end up in "upstream" — I don't actually
know how they work
On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote:
On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote:
This (A and B below) has the advantage of being quite explicit. The
original proposal
1) allow standard packages to be pip packages
2) drop the contents of
On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri
wrote:
> This (A and B below) has the advantage of being quite explicit. The
> original proposal
>
> 1) allow standard packages to be pip packages
>
> 2) drop the contents of upstream/ from the Sage source tarballs.
>
> sounds explicit, but the
On Mon, Feb 19, 2024 at 5:16 PM Matthias Koeppe
wrote:
> On Monday, February 19, 2024 at 5:42:08 AM UTC-8 tobia...@gmx.de wrote:
>
> This discussion about the need to fix the version of pytest *and its
> runtime dependencies* is almost comical.
>
>
> No, you are in the wrong thread.
>
> This
On Monday, February 19, 2024 at 5:42:08 AM UTC-8 tobia...@gmx.de wrote:
This discussion about the need to fix the version of pytest *and its
runtime dependencies* is almost comical.
No, you are in the wrong thread.
This thread is about the general policy for standard packages, not about
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,
On Sunday, February 18, 2024 at 10:05:21 AM UTC-8 Dima Pasechnik wrote:
On Sun, Feb 18, 2024 at 5:24 PM Matthias Koeppe
wrote:
On Sunday, February 18, 2024 at 9:07:04 AM UTC-8 Dima Pasechnik wrote:
2) The major improvement is that sagelib will be easier to install into an
existing venv,
On Sun, Feb 18, 2024 at 6:57 PM Nathan Dunfield
wrote:
> On Sunday, February 18, 2024 at 12:14:58 PM UTC-6 Dima Pasechnik wrote:
>
> Reading:
> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-source-types
>
>
> The wheel you talk about is just another packaging
On Sunday, February 18, 2024 at 12:14:58 PM UTC-6 Dima Pasechnik wrote:
Reading:
https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-source-types
The wheel you talk about is just another packaging of a source package,
isn't it?
No.
Well, I might have used
On Sun, Feb 18, 2024 at 6:09 PM Matthias Koeppe
wrote:
> On Sunday, February 18, 2024 at 10:05:21 AM UTC-8 Dima Pasechnik wrote:
>
> On Sun, Feb 18, 2024 at 5:24 PM Matthias Koeppe
> wrote:
>
> On Sunday, February 18, 2024 at 9:07:04 AM UTC-8 Dima Pasechnik wrote:
>
> 1) you can even just get a
On Sun, Feb 18, 2024 at 5:15 PM Matthias Koeppe
wrote:
> On Sunday, February 18, 2024 at 4:40:35 AM UTC-8 Dima Pasechnik wrote:
>
> On 17 February 2024 23:31:43 GMT, Matthias Koeppe
> wrote:
> >On Saturday, February 17, 2024 at 3:04:49 PM UTC-8 Nathan Dunfield wrote:
> >"wheel" type Sage
On Sunday, February 18, 2024 at 10:05:21 AM UTC-8 Dima Pasechnik wrote:
On Sun, Feb 18, 2024 at 5:24 PM Matthias Koeppe
wrote:
On Sunday, February 18, 2024 at 9:07:04 AM UTC-8 Dima Pasechnik wrote:
1) you can even just get a binary wheel of pytest installed - it is very
fast, and robust.
On Sun, Feb 18, 2024 at 5:24 PM Matthias Koeppe
wrote:
> On Sunday, February 18, 2024 at 9:07:04 AM UTC-8 Dima Pasechnik wrote:
>
> 1) you can even just get a binary wheel of pytest installed - it is very
> fast, and robust.
>
>
> Yes, that's what my PR
On Sunday, February 18, 2024 at 9:07:04 AM UTC-8 Dima Pasechnik wrote:
1) you can even just get a binary wheel of pytest installed - it is very
fast, and robust.
Yes, that's what my PR https://github.com/sagemath/sage/pull/37301 does. It
installs pytest as a "wheel" package.
Whether you
On Sunday, February 18, 2024 at 4:40:35 AM UTC-8 Dima Pasechnik wrote:
On 17 February 2024 23:31:43 GMT, Matthias Koeppe
wrote:
>On Saturday, February 17, 2024 at 3:04:49 PM UTC-8 Nathan Dunfield wrote:
>"wheel" type Sage packages, each of which is
>primarily just the version number of a
On 18 February 2024 15:51:27 GMT, Nathan Dunfield wrote:
>On Sunday, February 18, 2024 at 6:26:28 AM UTC-6 Dima Pasechnik wrote:
>
>I cannot imagine CI breaking down by, say, pytest.
>
>
>I can definitely see that happening, and indeed it seems to have done so
>for other projects:
>
On Sunday, February 18, 2024 at 6:26:28 AM UTC-6 Dima Pasechnik wrote:
I cannot imagine CI breaking down by, say, pytest.
I can definitely see that happening, and indeed it seems to have done so
for other projects:
https://github.com/pytest-dev/pytest/issues/9765
On 17 February 2024 23:31:43 GMT, Matthias Koeppe
wrote:
>On Saturday, February 17, 2024 at 3:04:49 PM UTC-8 Nathan Dunfield wrote:
>
>It seems to me that the "wheel" type Sage packages, each of which is
>primarily just the version number of a file on PyPI and its hash, is like a
On 17 February 2024 23:04:49 GMT, Nathan Dunfield wrote:
>On Saturday, February 17, 2024 at 1:13:33 PM UTC-6 Dima Pasechnik wrote:
>
>My proposal is in fact aimed at reducing the number of pinned Sage
>dependecies, drastically.
>
>Because most of them are either dependencies of Jupyterlab,
On Saturday, February 17, 2024 at 3:04:49 PM UTC-8 Nathan Dunfield wrote:
It seems to me that the "wheel" type Sage packages, each of which is
primarily just the version number of a file on PyPI and its hash, is like a
"requirements.txt" file (or "conda-lock" file, for that matter) spread over
On Saturday, February 17, 2024 at 1:13:33 PM UTC-6 Dima Pasechnik wrote:
My proposal is in fact aimed at reducing the number of pinned Sage
dependecies, drastically.
Because most of them are either dependencies of Jupyterlab, or of Sphinx,
or of Python build system, and none of the them
On Saturday, February 17, 2024 at 11:13:33 AM UTC-8 Dima Pasechnik wrote:
On 17 February 2024 17:16:07 GMT, Matthias Koeppe
wrote:
>I share the same concern based on the amplification of the failure
>probability, due to the large number of dependencies in Sage.
My proposal is in fact aimed
On 17 February 2024 17:16:07 GMT, Matthias Koeppe
wrote:
>On Saturday, February 17, 2024 at 7:06:27 AM UTC-8 Nathan Dunfield wrote:
>
>On Friday, February 16, 2024 at 11:17:37 PM UTC-6 Matthias Koeppe wrote:
>
>If one does not care about the use case without internet access, then it's
>just
On 17 February 2024 15:01:14 GMT, Kwankyu Lee wrote:
>
>
>there are ways to use pip without internet, with the necessary wheels
>pre-fetched.
>That's what Sage does with wheel packages.
>
>
>Yes. This is a sage package of source type "wheel", as Matthias explained.
>
>
>The difference
On Saturday, February 17, 2024 at 7:06:27 AM UTC-8 Nathan Dunfield wrote:
On Friday, February 16, 2024 at 11:17:37 PM UTC-6 Matthias Koeppe wrote:
If one does not care about the use case without internet access, then it's
just the following:
- Pinning, as you mentioned (see also
On Friday, February 16, 2024 at 11:17:37 PM UTC-6 Matthias Koeppe wrote:
If one does not care about the use case without internet access, then it's
just the following:
- Pinning, as you mentioned (see also
https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ above,
where I
there are ways to use pip without internet, with the necessary wheels
pre-fetched.
That's what Sage does with wheel packages.
Yes. This is a sage package of source type "wheel", as Matthias explained.
The difference between wheel packages vs pip packages is that the latter
don't require
On 17 February 2024 02:26:32 GMT, Kwankyu Lee wrote:
>
>
>
>
>By default the package content would be fetched, as pip does,
>
>
>Not just as pip does, but by actually calling "pip" to contact PyPI.
>
>
>and that would mean the default configuration for sage would require
>internet at
On 17 February 2024 02:26:32 GMT, Kwankyu Lee wrote:
>
>
>
>
>By default the package content would be fetched, as pip does,
>
>
>Not just as pip does, but by actually calling "pip" to contact PyPI.
>
>
>and that would mean the default configuration for sage would require
>internet at install
On Friday, February 16, 2024 at 8:44:06 PM UTC-8 Nathan Dunfield wrote:
Dima mentioned "tox" [1] as an example of a "standard" package that would
benefit from being switched to a "pip" package. The "tox" package is pure
python, so could also made a "wheel" package, which are already allowed
Dima mentioned "tox" [1] as an example of a "standard" package that would
benefit from being switched to a "pip" package. The "tox" package is pure
python, so could also made a "wheel" package, which are already allowed for
standard package, for example [2]. I'm having difficultly
On Friday, February 16, 2024 at 6:26:32 PM UTC-8 Kwankyu Lee wrote:
By default the package content would be fetched, as pip does,
Not just as pip does, but by actually calling "pip" to contact PyPI.
and that would mean the default configuration for sage would require
internet at install
By default the package content would be fetched, as pip does,
Not just as pip does, but by actually calling "pip" to contact PyPI.
and that would mean the default configuration for sage would require
internet at install time.
That's right.
Then Dima's proposal implies assuming
On Friday, February 16, 2024 at 3:57:06 PM UTC-8 Nils Bruin wrote:
As far as I understand, the proposal is to allow sage "packages" to be
closer to more standard python prerequisites by letting them be resolved by
pip packages.
No, we already have such Sage packages: This is just one of the 4
As far as I understand, the proposal is to allow sage "packages" to be
closer to more standard python prerequisites by letting them be resolved by
pip packages. By default the package content would be fetched, as pip does,
and that would mean the default configuration for sage would require
On Monday, February 12, 2024 at 4:05:05 PM UTC-8 Dima Pasechnik wrote:
On Mon, Feb 12, 2024 at 11:52 PM Matthias Koeppe
wrote:
> If there are relevant use cases without internet connectivity (I have no
opinion to offer on this), then the release tarball has exactly the right
contents.
This
On Mon, Feb 12, 2024 at 11:52 PM Matthias Koeppe
wrote:
>
> I'll now offer:
>
> Opinion 1. Nobody needs to care in the slightest what the size of that
> release tarball is.
Not quite true. E.g. the mirrors are not of infinite size, e.g. some
projects (symengine is an example, IIRC) on PyPI get
What does this (a discussion of how Sage specifies version restrictions)
have to do with the proposal? If it's relevant, that was not clear in the
original proposal, so please clarify. It sounds like you might be proposing
removing version checks on many of the packages Sage uses, or at least
On Mon, Feb 12, 2024 at 10:01 PM Matthias Koeppe
wrote:
>
> On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:
>
> requirements.txt might as well specify the range, and this is used too e.g.
>
> build/pkgs/phitigra/requirements.txt has
> phitigra>=0.2.6
>
>
> Yes, as I said
On Mon, Feb 12, 2024 at 10:11 PM Matthias Koeppe
wrote:
>
> On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:
>
> > 2. Also the large Sage source tarball does not "vendor". It is a shipment
> > of a distribution. Distributions don't "vendor". It's the job of a
> >
On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:
> 2. Also the large Sage source tarball does not "vendor". It is a shipment
of a distribution. Distributions don't "vendor". It's the job of a
distribution to ship its components.
This is not correct. Sage is not a
On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:
requirements.txt might as well specify the range, and this is used too e.g.
build/pkgs/phitigra/requirements.txt has
phitigra>=0.2.6
Yes, as I said
in https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ,
On Mon, Feb 12, 2024 at 6:02 PM Matthias Koeppe
wrote:
>
> On Monday, February 12, 2024 at 3:18:05 AM UTC-8 Dima Pasechnik wrote:
>
> > Pinning packages to a set of tested working versions is a standard
practice, and as a matter of fact part of best practices to achieve
stability in various
On Monday, February 12, 2024 at 3:18:05 AM UTC-8 Dima Pasechnik wrote:
> Pinning packages to a set of tested working versions is a standard
practice, and as a matter of fact part of best practices to achieve
stability in various deployment situations, reproducibility, etc.
>
> In the Python
On Mon, Feb 12, 2024 at 12:34 PM kcrisman wrote:
>
> As part of this thread, I'd again ask for a discussion of the following
> situation I asked in the other thread. Dima had some interesting points
> about a less-vendored approach saving disk space etc., but it would be
> helpful to have
As part of this thread, I'd again ask for a discussion of the following
situation I asked in the other thread. Dima had some interesting points
about a less-vendored approach saving disk space etc., but it would be
helpful to have input from people who have had to install Sage in these
kinds
On Mon, Feb 12, 2024 at 12:57 AM Matthias Koeppe
wrote:
>
> On Sunday, February 11, 2024 at 3:34:46 PM UTC-8 Dima Pasechnik wrote:
>
> On 11 February 2024 22:47:24 GMT, Matthias Koeppe
> wrote:
> >On Sunday, February 11, 2024 at 1:46:40 PM UTC-8 Matthias Koeppe wrote:
> >
> >I'll make an
On Sunday, February 11, 2024 at 3:34:46 PM UTC-8 Dima Pasechnik wrote:
On 11 February 2024 22:47:24 GMT, Matthias Koeppe
wrote:
>On Sunday, February 11, 2024 at 1:46:40 PM UTC-8 Matthias Koeppe wrote:
>
>I'll make an attempt to quantify this cost
>
>Here's an illustration of the workflow
On 11 February 2024 22:47:24 GMT, Matthias Koeppe
wrote:
>On Sunday, February 11, 2024 at 1:46:40 PM UTC-8 Matthias Koeppe wrote:
>
>I'll make an attempt to quantify this cost
>
>
>Here's an illustration of the workflow for making python_build a standard
>"wheel" package, as proposed in
On 11 February 2024 21:46:40 GMT, Matthias Koeppe
wrote:
>I'll provide some context and pointers that readers may find helpful to
>participate in the discussion and vote.
>- terminology:
>https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
>- tooling:
As I mentioned in the thread that motivated this one, it would be relevant
to stablish if it is possible to move those packages from standard to pip,
while still having a way to install sage without an internet connection.
If the effort is not too much, I think it would make sense to provide
On Sunday, February 11, 2024 at 12:26:41 PM UTC-8 Dima Pasechnik wrote:
On 11 February 2024 19:50:17 GMT, Matthias Koeppe
wrote:
>I think it's a bit too quick to already call a vote. I would suggest that
>you take the time to collect and link previous discussions on this topic,
>so that
On 11 February 2024 19:50:17 GMT, Matthias Koeppe
wrote:
>I think it's a bit too quick to already call a vote. I would suggest that
>you take the time to collect and link previous discussions on this topic,
>so that participants can review the known arguments, viewpoints, and
76 matches
Mail list logo
