Proposal to allow downloads during build of optional packages

120 views
Skip to first unread message

gmou3

unread,
Dec 31, 2024, 1:56:16 PM12/31/24
to sage-devel
Currently internet connection is not available during the building of a package.
I propose to change this (at least) for optional packages. The benefit of this is that we need not add all the dependencies as sage pkgs, as it the case now. If there are no important drawbacks to this policy change, I would even suggest allowing internet connection for all pkgs, and clearing the sage pkgs folder of any dependencies.

For example, the addition of the package ccache requires the addition of its dependencies hiredis, xxhash, and zstd. This requires more work and maintenance and dilutes the content of pkgs with many dependencies.

See the relevant PR:

Kwankyu Lee

unread,
Dec 31, 2024, 9:04:22 PM12/31/24
to sage-devel
To be clear, note that we have two types of packages: standard and optional. Standard packages are by definition those packages installed by default. See https://doc-release--sagemath.netlify.app/html/en/developer/packaging#package-types

The proposal is about allowing internet connection for optional packages. For #39226, we need a definite decision here.

I think allowing internet connection for standard packages is a much more complicated matter. We may discuss it here, but we may not reach to a consensus.

Nathan Dunfield

unread,
Jan 1, 2025, 9:30:20 AM1/1/25
to sage-devel
On Tuesday, December 31, 2024 at 8:04:22 PM UTC-6 Kwankyu Lee wrote:
To be clear, note that we have two types of packages: standard and optional. Standard packages are by definition those packages installed by default. See https://doc-release--sagemath.netlify.app/html/en/developer/packaging#package-types

The proposal is about allowing internet connection for optional packages. For #39226, we need a definite decision here.

An internet connection is already required for many optional packages, namely those that are "pip packages" which pull the relevant wheels off PyPI [1].  So I think extending that privilege to optional packages that are implemented as "normal packages" is not really a change from the end-users' perspective.

Best,

Nathan  

 
Reply all
Reply to author
Forward
0 new messages