Please Dima, let me stop this quoting business from your private messages.
Dima's response:
> It is perfectly avoidable, as I explained in more details, which you have
chosen not to copy here.
OK. Then which one of these quotes from you is the details explaining how
to install sage from
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", that is, wheel packages. For its
replacement, you propose to fetch wheels directly from PyPI by switching to
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
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
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.
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. Distributions do distribution stuff.
More questions?
--
You received this
On Wednesday, June 5, 2024 at 8:00:54 PM UTC+1 Matthias Koeppe wrote:
On Wednesday, June 5, 2024 at 9:46:05 AM UTC-7 Dima Pasechnik wrote:
On Monday, June 3, 2024 at 8:16:30 PM UTC+1 Matthias Koeppe wrote:
Unlikely that we would add a package to the Sage distribution that builds a
Rust
On Wednesday, June 5, 2024 at 9:46:05 AM UTC-7 Dima Pasechnik wrote:
On Monday, June 3, 2024 at 8:16:30 PM UTC+1 Matthias Koeppe wrote:
Unlikely that we would add a package to the Sage distribution that builds a
Rust library from source.
Not so long ago we added support for installing Python
On Monday, June 3, 2024 at 8:16:30 PM UTC+1 Matthias Koeppe wrote:
Unlikely that we would add a package to the Sage distribution that builds a
Rust library from source.
Not so long ago we added support for installing Python packages from
platform-independent wheels. We did this to sidestep
On 4 June 2024 18:46:44 BST, kcrisman wrote:
>
>
>Yes. I am all for removing "no internet connection" assumption in
>installing the sage distribution from source.
>
>
>Since we don't ship binaries, I'd like to hear from those who have had to
>install Sage in circumstances with slow/no
Yes. I am all for removing "no internet connection" assumption in
installing the sage distribution from source.
Since we don't ship binaries, I'd like to hear from those who have had to
install Sage in circumstances with slow/no internet situations about this
(e.g. several of our French
There is no need to remove it - it suffices to convert it to a pip package.
(yes, for this we need to allow standard pip packages - as I have been
proposing).
Yes. I am all for removing "no internet connection" assumption in
installing the sage distribution from source.
--
You received
On Monday, June 3, 2024 at 9:10:56 PM UTC+1 Matthias Koeppe wrote:
On Monday, June 3, 2024 at 12:41:41 PM UTC-7 Michael Orlitzky wrote:
Rust is not nearly as portable as C, and has an unstable ABI that makes
shipping compatible versions of packages from multiple sources nearly
impossible.
Yes, this is well worth discussing.
But note that there is one non-trivial interaction of Sage with Jupyter via
the recently added Live Documentation feature (jupyter-sphinx).
Already "pip install jupyter-sphinx" pulls in the Rust-based package
rpds_py.
On Monday, June 3, 2024 at 2:47:14 PM
On 3 June 2024 23:47:14 CEST, Kwankyu Lee wrote:
>
>
>Likewise, we will soon add support for installing Python packages from
>platform-dependent wheels. This is needed for updating some Jupyter
>components that have started to use Rust (https://github.com/crate-py/rpds,
>a dependency of
Likewise, we will soon add support for installing Python packages from
platform-dependent wheels. This is needed for updating some Jupyter
components that have started to use Rust (https://github.com/crate-py/rpds,
a dependency of jsonschema).
First sorry for an off-topic comment. If we
On Mon, 2024-06-03 at 12:54 -0700, Matthias Koeppe wrote:
>
> Could you share details regarding this? I'm not sure who "we" is in what
> you write, but in the last Jupyter PR that I prepared, I had to use some
> older versions of some packages to avoid pulling in the Rust dependency at
> this
On Monday, June 3, 2024 at 12:41:41 PM UTC-7 Michael Orlitzky wrote:
Rust is not nearly as portable as C, and has an unstable ABI that makes
shipping compatible versions of packages from multiple sources nearly
impossible.
I share this concern about ABI compatibility, and would therefore for
On Monday, June 3, 2024 at 12:41:41 PM UTC-7 Michael Orlitzky wrote:
On Sat, 2024-06-01 at 10:02 -0700, Matthias Koeppe wrote:
> we will soon add support for installing Python packages from
> platform-dependent wheels. This is needed for updating some Jupyter
> components that have started to
On Sat, 2024-06-01 at 10:02 -0700, Matthias Koeppe wrote:
> Unlikely that we would add a package to the Sage distribution that builds a
> Rust library from source.
>
> Not so long ago we added support for installing Python packages from
> platform-independent wheels. We did this to sidestep
Unlikely that we would add a package to the Sage distribution that builds a
Rust library from source.
Not so long ago we added support for installing Python packages from
platform-independent wheels. We did this to sidestep the concern of
shipping more and more of Javascript (Node.js)
It seems that Dima Pasechnik's replies are not displaying here, so I will
add them:
*First message:*
*Hi,*
*pyo3 seems to be for calling Python from Rust. You need the opposite, Rust
from Python, e.g. as described in
https://bheisler.github.io/post/calling-rust-in-python/
32 matches
Mail list logo
