I explained to Kwankyu that I mean "mirroring" in the usual sense of this
word, not the one he thought.
OK. Sage tarballs and the wheels are uploaded to our mirror sites. So wheel
packages end up in the mirror sites. This is what you say "mirroring PyPI".
You object to "mirroring PyPI",
On Monday, June 10, 2024 at 11:10:34 AM UTC-7 Dima Pasechnik wrote:
We are discussing your (general) proposal to provide binary wheels for
packages by mirroring PyPI.
That is where gigabytes come from.
E.g. the binary wheels for scipy (with one version of Python) add up to
about 200Mb.
On 10 June 2024 17:27:55 BST, Matthias Koeppe wrote:
>On Monday, June 10, 2024 at 7:52:09 AM UTC-7 Kwankyu Lee wrote:
>
>This is Dima's response:
>> [...] multi-Gigabyte territory.
>
>
>For a fact-based discussion, people may want to look at the actual size of
>the wheels of the only
On 10 June 2024 17:21:16 BST, Matthias Koeppe wrote:
>On Monday, June 10, 2024 at 7:37:48 AM UTC-7 Kwankyu Lee wrote:
>
>So, why do we need to mirror PyPI ?
>
>
>I understand "mirroring PyPI" as what we do with "wheel" packages, that
>is, delivering the wheel (downloaded from PyPI) of the
+1
On 10 June 2024 17:41:07 BST, Nathan Dunfield wrote:
>This makes sense to me.
>
>Nathan
>
>On Sunday, October 1, 2023 at 2:29:55 PM UTC-5 Matthias Koeppe wrote:
>
>I propose to demote this package to experimental.
>- It has been declared dead at least once -
I'll remark that the approach of my PR
https://github.com/sagemath/sage/pull/36380 takes brial to the same level
as the existing optional packages bliss, coxeter3, sirocco, tdlib, etc. and
applies the same approach to the Sage library code depending on the
library: It defines a separately
+1 for me too
On Mon, 10 Jun 2024 at 18:41, Nathan Dunfield wrote:
>
> This makes sense to me.
>
> Nathan
>
> On Sunday, October 1, 2023 at 2:29:55 PM UTC-5 Matthias Koeppe wrote:
>
> I propose to demote this package to experimental.
> - It has been declared dead at least once -
>
On Monday, June 10, 2024 at 7:52:09 AM UTC-7 Kwankyu Lee wrote:
This is Dima's response:
> [...] multi-Gigabyte territory.
For a fact-based discussion, people may want to look at the actual size of
the wheels of the only rust-based package that we are discussing.
On Monday, June 10, 2024 at 7:37:48 AM UTC-7 Kwankyu Lee wrote:
So, why do we need to mirror PyPI ?
I understand "mirroring PyPI" as what we do with "wheel" packages, that
is, delivering the wheel (downloaded from PyPI) of the specified version in
the sage tarball.
Exactly.
--
You
This makes sense to me.
Nathan
On Sunday, October 1, 2023 at 2:29:55 PM UTC-5 Matthias Koeppe wrote:
I propose to demote this package to experimental.
- It has been declared dead at least once -
https://martinralbrecht.wordpress.com/2015/06/13/polybori-is-dead-it-needs-your-help/
- It has no
On Mon, Jun 10, 2024 at 3:52 PM Kwankyu Lee wrote:
>
> This is Dima's response:
>
> > None are relevant:
> > (1) can be trivially achieved without mirroring.
> > (2) is irrelevant here, as creating a tarball with all these binary
> > wheels pushes us into multi-Gigabyte territory.
> > That is,
On Monday, June 10, 2024 at 3:37:48 PM UTC+1 Kwankyu Lee wrote:
So, why do we need to mirror PyPI ?
I understand "mirroring PyPI" as what we do with "wheel" packages, that
is, delivering the wheel (downloaded from PyPI) of the specified version in
the sage tarball.
This is not
On Mon, Jun 10, 2024 at 2:18 PM Kwankyu Lee wrote:
>
> To add variation to this boring discussion, let me intervene:
>
>
> So, why do we need to mirror PyPI ?
>
>
> From this discussion, I guess that the answer is
>
> 1. We want to pin the version of standard package
> 2. We do not want to
This is Dima's response:
> None are relevant:
> (1) can be trivially achieved without mirroring.
> (2) is irrelevant here, as creating a tarball with all these binary
> wheels pushes us into multi-Gigabyte territory.
> That is, you'd need prefetch the set of binary wheels for your machine
>
So, why do we need to mirror PyPI ?
I understand "mirroring PyPI" as what we do with "wheel" packages, that
is, delivering the wheel (downloaded from PyPI) of the specified version in
the sage tarball.
--
You received this message because you are subscribed to the Google Groups
To add variation to this boring discussion, let me intervene:
So, why do we need to mirror PyPI ?
>From this discussion, I guess that the answer is
1. We want to pin the version of standard package
2. We do not want to assume internet connection
Is there other reason, Matthias?
Dima,
On Monday, June 10, 2024 at 1:53:59 AM UTC+1 Matthias Koeppe wrote:
On Sunday, June 9, 2024 at 5:25:54 PM UTC-7 Dima Pasechnik wrote:
Is there any Python project which resorts to mirroring binary PyPI wheels?
Sage-the-Python-project does not do this.
Sage-the-distribution does.
Why do you even need to build Python 3.11? Don't you have system-wide
3.12 which you can use?
It would help if you post full toplevel config.log.
It would also be good to put Sage to a directory which doesn't have
non-ASCII characters in the full path, and no spaces in it - it seems
it's not the
Currently ther are about 90 open PR's that are not drafts but don't have
any state label set (see this list
I have prepared a release candidate for cysignals 1.12.0
- https://pypi.org/project/cysignals/1.12.0rc1/
- Removes optional compile-time dependency on PARI/GP
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
20 matches
Mail list logo
